On this page
- Why does an app Claude built still need a security check?
- What does /security-review actually check?
- How do I run a security check step by step?
- 1Open Claude Code in your project folder
- 2Run /security-review on your latest changes
- 3Ask for a full-project review
- 4Check your libraries with npm audit
- 5Fix in order — one finding at a time
- How do I read the results — and what do I fix first?
- How do I check accessibility basics?
- Does my privacy policy match what the site really collects?
- Ann's pre-launch checklist
- Can I make the security check automatic?
- Questions, answered
Before you launch anything Claude Code built for you, run two checks: the built-in `/security-review` command, which looks at the changes on your current branch, and a full-project security prompt, which asks Claude to go through every file. Then add three quick extras — npm audit for your libraries, an accessibility pass, and a privacy-policy sanity check. Claude built it fast. But nobody checked it yet, and once real people put their names, phone numbers and payments into it, that part is on you, not on Claude.
Why does an app Claude built still need a security check?
Because "it works" and "it's safe" are two different questions. When you ask Claude for a booking form, it builds a booking form that works. It doesn't automatically stop and ask: can a stranger see other customers' bookings? Is the database password sitting inside the code? Can someone type a script into the "name" field? Those are the questions a developer would ask before launch — and if you're a vibe coder, there's no developer in the room. So you ask Claude to put on a different hat: the security reviewer.
Anthropic says this plainly in its own Claude Code security docs: you're responsible for reviewing proposed code and commands before you approve them. Claude is a great builder and a great reviewer — but only when you ask it to review.
What does /security-review actually check?
/security-review is a command that comes built into Claude Code. According to the Claude Code commands reference, it analyzes the changes on your current branch for security vulnerabilities — it reviews the difference between your branch and the default branch on GitHub ("origin"), looking for risks like injection, authentication problems and data exposure.
Anthropic's open-source repository for the matching GitHub Action lists the kinds of problems this analysis looks for, including:
- Injection attacks — like SQL injection, where someone sneaks database commands into a form field.
- Authentication and authorization — broken logins, users who can reach things they shouldn't.
- Data exposure — passwords or keys written into the code, sensitive data in logs.
- Cross-site scripting (XSS) — someone planting a script on your page that runs in other visitors' browsers.
- Configuration — insecure defaults, missing security headers.
- Supply chain — vulnerable libraries (dependencies) your app relies on.
How do I run a security check step by step?
Open Claude Code in your project folder
Open the terminal in the folder of the app you want to check and start Claude Code. New to it? Start with What is Claude Code.
Run /security-review on your latest changes
/security-review
Best habit: run it every time Claude finishes a new feature on a branch, before you merge it. If you get an error about origin, your project isn't connected to GitHub yet — just move on to step 3.
Ask for a full-project review
This is the one that matters before a first launch. Copy it exactly:
Do a full security review of the whole project, not just recent changes. Go through every file and look for: authentication and permissions; access to other users' data; SQL injection and XSS; file uploads; API keys and passwords written in the code; libraries with known vulnerabilities. List findings by severity, explain each in plain language, and don't change anything until I approve.
The last sentence is the important one. You want a report first, not a surprise rewrite of your app the night before launch.
Check your libraries with npm audit
If your project has a package.json file (most JavaScript sites and apps do), run:
npm audit
It sends a description of your project's libraries to the npm registry and gets back a report of known vulnerabilities. npm audit fix applies the safe updates. Avoid npm audit fix --force unless you know what you're doing — npm's own docs warn it can install major updates outside the versions you set, which can break your app. Not sure? Ask Claude: "Explain this npm audit report in plain language and tell me what's safe to fix."
Fix in order — one finding at a time
Approve fixes one at a time, test the app after each, and run the review again at the end. The order is in the next section.
How do I read the results — and what do I fix first?
You'll get a list of findings, usually marked high, medium or low. Don't panic and don't try to fix everything at once. Here's the order I use:
- 1. Secrets in the code. An API key, database password or Stripe key written inside a file. Rotate it immediately — create a new key in that service's dashboard and delete the old one — then move it to an environment variable. Deleting it from the code isn't enough: if the code was ever pushed to GitHub, assume the old key is out there.
- 2. Other people's data exposed. Anything that lets one user see, change or delete another user's records — bookings, leads, invoices. Fix before launch, no exceptions.
- 3. Injection and XSS. Forms and fields that accept dangerous input.
- 4. Everything else. Missing headers, outdated libraries, "nice to have" hardening. Plan them, but they usually don't block launch.
| Finding | What it means in plain words | What to do |
|---|---|---|
| Hardcoded secret / API key | A password to one of your services is sitting inside the code | Rotate the key now, then move it to an environment variable |
| Broken access control / IDOR | Change a number in the link and you see someone else's record | Ask Claude to check ownership on every page and API route |
| SQL injection | Text typed into a form can run commands on your database | Ask Claude to use parameterized queries everywhere |
| XSS | Someone can plant a script that runs in your visitors' browsers | Ask Claude to escape or sanitize everything users type |
| Unsafe file upload | People can upload any file type, any size, anywhere | Limit types and size; store uploads outside the public folder |
| Vulnerable dependency | A library you use has a known, published hole | npm audit fix, then test the app |
| Missing security headers | The browser isn't told to apply some extra protections | Usually lower priority — ask Claude to add them after the urgent fixes |
Not sure what a finding means? Paste it back to Claude and ask: "Explain this like I'm not a developer. How bad is it, and what's the smallest safe fix?"
How do I check accessibility basics?
Accessibility means people using screen readers, keyboards or larger text can actually use your site. The international standard is WCAG by the W3C, and the latest version is WCAG 2.2. Ask Claude to audit against it:
Audit the site against WCAG 2.2 level AA basics: alt text on images, color contrast of text, full keyboard navigation (including menus and forms), visible focus, labels on every form field, and clear error messages. List what's missing page by page, in plain language. Don't change anything yet.
Does my privacy policy match what the site really collects?
This is the one almost everybody skips. Claude often generates a privacy policy page from a template — and then you add a contact form, Google Analytics, a Facebook pixel and Stripe, and the policy never mentions any of them. Claude can read both the code and the policy, so let it compare:
List everything this site actually collects or shares: every form field, cookies, analytics and tracking scripts, payment providers, email tools, and any third-party service that receives user data. Then compare that list with our privacy policy page and show me what the policy is missing or says incorrectly. Don't rewrite the policy — just give me the gaps.
Privacy laws exist in Israel, the US and the EU, and they differ. Claude can show you the gaps — it can't tell you what the law requires for your business. For legal sign-off, take that list to a lawyer. You'll save them (and yourself) a lot of time.
Ann's pre-launch checklist
- `/security-review` after every new feature, before merging.
- The full-project prompt once before the first launch, and again after big changes.
- `npm audit` — and no
--forceunless I understand why. - No secrets in the code. Every key in environment variables; any key that was ever in the code gets rotated.
- Two test accounts. I log in as user A and try to open user B's records. If I can, it's not ready.
- Accessibility audit against WCAG 2.2 AA — and I tab through the main form with the keyboard myself.
- Privacy policy gaps listed by Claude, reviewed by a lawyer.
- Write the rules into CLAUDE.md — "never put keys in code, always check who owns the data" — so Claude remembers next time. See How to write a good CLAUDE.md.
Can I make the security check automatic?
Yes, if your project lives on GitHub. Anthropic publishes an open-source GitHub Action, anthropics/claude-code-security-review, that runs the same kind of analysis on every pull request and leaves comments on the lines it's worried about. It only analyzes the files changed in the pull request, and its README warns it isn't hardened against prompt injection — so use it only on pull requests you trust. For most solo vibe coders, running /security-review and the full-project prompt by hand is plenty.
Want to build — and launch — with confidence?
In my Hebrew Zoom course we build real things with Claude Code, step by step, including how to check them before they go live.
Questions, answered
What does /security-review do in Claude Code?
It's a built-in Claude Code command that analyzes the changes on your current branch for security vulnerabilities. It reviews the difference between your branch and the default branch on your origin remote, looking for risks like injection, authentication issues and data exposure. It needs your project to have an origin remote (for example, a GitHub repository).
Does /security-review check my whole project?
No. It focuses on the pending changes on your current branch. To check an entire app — especially one Claude built from scratch — ask Claude for a full-project review in plain words: go through every file, list findings by severity, and don't change anything until you approve.
I found an API key in my code. What do I do?
Rotate it right away: create a new key in that service's dashboard and revoke the old one. Then store the new key in an environment variable instead of the code. Removing it from the file alone isn't enough, because the old key may already be in your Git history or on GitHub.
Is npm audit enough to secure my app?
No. npm audit only reports known vulnerabilities in the libraries your project uses. It doesn't look at your own code — like who can see which data, or how forms handle input. Use it together with /security-review and a full-project review.
Can Claude make my site legally accessible or GDPR-compliant?
Claude can audit your site against WCAG 2.2 AA basics and compare what your site collects with what your privacy policy says. That's a very useful first pass, but it's not legal advice or a certification. For legal sign-off, use a lawyer and, where required, an accessibility professional.
Should I let Claude fix the security findings automatically?
Ask for the report first and approve fixes one by one, starting with secrets in the code and anything that exposes other users' data. Test the app after each fix and run the review again at the end.
Reading is step one. Doing it is the club.
New skills and guides first, courses as they're released, and a community that answers when you get stuck. $69/month. One price covers every course. No commitment, cancel anytime.
AI changes every week. Stay current in 2 minutes.
Every Monday: what changed in ChatGPT, Claude and Gemini, why it matters, and one thing to try. Free.
Written by Ann Alalouf. Spotted something out of date? Tell us — we keep these current. Published Oct 29, 2026.
