Claude Code Security Review: What It Actually Catches, and What It Misses

A Claude code security review is genuinely useful, and it is not a full security review. Both things are true at once. When Claude reads your codebase, whether through the /security-review command, the anthropics/claude-code-security-review GitHub Action, or the built-in Claude Code Security capability, it reasons about your code far better than a traditional linter. It reliably flags injection, cross-site scripting, unsafe deserialization, and hardcoded secrets. You should run it.

But every one of those checks has the same boundary: it reads source code. It never runs your app. It cannot send an authenticated request, forge a token, or test whether user A can reach user B's data. And that runtime gap is exactly where AI-built apps break most often. This guide covers both halves honestly: what a Claude security review catches well, what it structurally cannot see, and how to review the rest.

What a Claude Code Security Review Actually Is

Whichever entry point you use, the mechanism underneath is source-code analysis, a smarter form of SAST:

All three read text and reason about it. None of them deploy your app and attack it. That is not a criticism, it is the category: static analysis is one layer of a security review, and Claude does that layer well.

What a Claude Code Security Review Catches

A Claude review is strong exactly where the vulnerability is legible in the code itself:

• Injection patterns (SQL, command, template) where untrusted input reaches a sink
• Cross-site scripting from unescaped output
• Hardcoded secrets and exposed API keys committed into source
• Unsafe deserialization and dangerous DOM APIs
• Obvious misuse of crypto or known-bad function calls

If the flaw is visible on the page, an AI reviewer that reads the page will usually find it. This is real value, and it is why the tool set off so much attention in 2026.

What a Claude Code Security Review Misses

Here is the boundary that no static pass, human or AI, fully closes: some code is only wrong when it runs. The most common vulnerability class in AI-built apps is broken access control, and it is nearly invisible to a reviewer reading source, because the code looks correct in isolation.

Consider a Server Action Claude might generate, and might well pass in a review:

export async function updateWorkspace(input: {
  workspaceId: string;
  name: string;
}) {
  const session = await getSession();

  if (!session) throw new Error("Unauthorized");

  return db.workspace.update({
    where: { id: input.workspaceId },
    data: { name: input.name },
  });
}

Read it as a code reviewer: there is an authentication check, an error on the unauthenticated path, a scoped update. Nothing here matches a known-bad pattern, so a source-code pass sees clean code. But the running app is exploitable: the code checks authentication, not ownership. Any logged-in user can update any workspace by changing workspaceId. That is a textbook IDOR / BOLA flaw, and you can only prove it by sending a request as user A for user B's workspaceId and watching it succeed.

A Claude security review will not do that. It cannot authenticate to your deployed app, cannot forge or replay a token, and cannot enumerate IDs against a live endpoint. The same blind spot applies to:

• Missing ownership checks that pass an authentication check (as above)
• Supabase RLS misconfiguration where policies exist but do not actually isolate rows
• JWT claim spoofing and trust in client-supplied identity
• Privilege escalation through admin routes reachable by standard users
• Business-logic flaws where each step is valid but the sequence is not

Every one of these can ship with source code that reads as correct. This is the exact gap the AppSec industry keeps pointing at: a review that "looks only at source code" trips on runtime threats. Runtime testing, by contrast, sends authenticated requests and manipulates tokens, that is where these flaws surface.

There's a deeper reason not to lean on an AI reviewing AI-written code: it is proofreading its own essay. When the same model that generated a pattern also reviews it, it tends to accept the very assumptions that produced the flaw, exactly like re-reading something you wrote and skimming past your own typo because your eye already knows what it was supposed to say. The errors you are least likely to catch are the ones you introduced yourself. A genuinely independent, adversarial pass, one that does not share the author's blind spots, is what surfaces them.

And the gap is not theoretical. Across 1,000 live Ubserve scans, 12.5% of AI-built apps shipped with an API endpoint or database table reachable with no authentication at all, precisely the access-control class a source-code review reads straight past.

How to Run a Complete Claude Code Security Review

Treat Claude's pass as step one, then cover the runtime layer it cannot reach:

1. Run the static pass. Use /security-review or the GitHub Action so every PR is scanned. Fix what it flags, injection, secrets, XSS, before it merges.
2. Confirm Claude Code itself is current. The tool has had its own disclosed, patched vulnerabilities (credential exfiltration and prompt-injection classes that target agent config). Updating closes those.
3. Test access control at runtime. For every mutation and data-read endpoint, send a request as one user for another user's resource ID and confirm it fails. This is the step that catches the updateWorkspace bug above.
4. Verify data isolation on the live app. If you use Supabase, confirm RLS actually blocks cross-tenant reads, not just that policies exist.
5. Trace every auth claim to a server-verified source. Anything derived from a client-supplied token or ID is suspect until proven otherwise.

Steps 3 through 5 are why a source-code review alone leaves you exposed, and why runtime exploit simulation exists as a distinct layer. Claude Code is one of many AI builders with this exact blind spot; our AI code security guide covers the pattern across all of them.

Claude Code Security Review: Complete Checklist

Static layer (what Claude covers)

• /security-review or the GitHub Action runs on every pull request
• Injection, XSS, and unsafe-deserialization findings resolved before merge
• No hardcoded secrets or exposed keys remain in source
• Claude Code updated past known disclosed vulnerabilities

Runtime layer (what it can't cover)

• Every mutation tested with a wrong-user resource ID (IDOR/BOLA)
• Every endpoint checks ownership, not just authentication
• Supabase RLS verified against live cross-tenant reads
• Admin routes confirmed unreachable by standard users
• Every auth claim traced to a server-verified source, not a client-supplied one

A Claude code security review is one of the best static passes available in 2026. It just cannot be the reviewer of what your app does when it runs, and that is precisely where the highest-severity flaws in AI-built apps live.

Run a free URL scan, no signup required. It behaves like an attacker against your live app, checking the runtime access-control and IDOR class a source-code review can't see. You only pay if it finds something, and if it does, paid plans unlock the full report, exact AI fix prompts, PDF export, and deeper audit coverage. For the manual alternative, see Ubserve vs. manual security review.