Is My Site at Risk of Hacking? /security-review Before You Ship

A login form whipped up with vibe coding, a customer-info entry page... you've confirmed it works, but the anxiety of "what if this gets hacked?" won't go away. Security is a specialized field, so it's hard for beginners to handle themselves. /security-review is a command that hands that check off to AI. Just 5 minutes right before you ship.

Definition

/security-review is a command that focuses on a code's security vulnerabilities (hacking risks). While a general code review looks at "is this well-written," this digs only into "are there any holes to break through." It mainly points out risks like these.

• Injection: An attack that controls the system by putting malicious code into an input field
• Auth holes: A problem where flimsy login/permission checks let someone access others' info
• Data exposure: A problem where sensitive info like passwords or API keys leaks out

How to use it (by difficulty)

Basics — run the security check

Type into the chat box.

/security-review

Then Claude Code scans recently changed code and analyzes security risks. When done, it shows a list of risk items with severity, like "input validation is missing here" or "a key is exposed as-is in this part." It tells you what's risky and why, and even how to fix it.

Applied — make it a pre-deploy routine

feature's done. run /security-review before deploy

Build the habit of always running it once right before launching, after finishing a feature. Put it as a fixed item on your launch checklist and you'll never forget the security check.

Advanced — double-check quality and security

/code-review

First check whether the code is well-written with /code-review (code quality review), then check security next.

/security-review

Filtering twice in quality → security order catches almost all the problems you can catch before launch.

Common pitfall — "nothing flagged so it's safe" isn't true

Nothing coming up in /security-review doesn't mean it's 100% safe. This is a tool that quickly filters common risks as a first pass. Still, running it vs. not is night and day. It reliably catches holes beginners often miss, like missing input validation. Think of it as a "cheap first line of defense," not a "perfect guarantee." Especially for code handling customer data, always run it.

A real case

I once built an input form to receive customer inquiries. It worked fine on screen, but running /security-review before deploy pointed out a part where input validation was missing. Had I shipped it as-is, someone could have put malicious code into the field and made trouble. I found and blocked it before launch — a 5-minute investment that prevented one incident.

Use it like this too

• Pre-deploy routine: Once every time as a fixed item on your launch checklist.
• Double-check: Filter twice with /code-review (quality review) then /security-review (security).
• What it looks at: Checks representative risks like injection, auth holes, and sensitive-info exposure.
• A must when handling customer data: Always run it on code where personal info flows, like forms, login, and payment.

Tip: When you find a risk in the security report, just say "fix this vulnerability" right there. Connect discovery and fixing in one flow.

Wrap-up

The key is one sentence. Make pre-deploy security checks a habit. You don't have to be an expert — one line of /security-review sets up a first line of defense. Especially if you handle customer info, it's not a choice but a must. An incident is too late once it breaks out — a 5-minute check is the cheapest prevention.

Based on: Claude Code v2.1.154 (2026.05)