Using Claude Code for Security Reviews
Claude catches common security issues well. Here's how to use it as a first-pass security review, and where it falls short.
I don't rely on Claude Code as a sole security reviewer, but I do use it as a fast first pass before code review. It catches a category of issues that are easy to miss when you're close to the code you wrote.
The security review prompt
At the end of any session touching auth, user input handling, or data access, I ask:
"Review this code for security issues. Focus on: input validation, authentication bypass paths, data exposure risks, injection vulnerabilities, and insecure defaults. List specific issues with line references, not general advice."
The "specific issues with line references, not general advice" instruction is important. Without it, Claude produces a list of generic security reminders that don't tell you anything about the actual code.
What Claude catches reliably
Missing input validation. User-supplied data used without sanitization or type checking. Claude spots this consistently.
SQL injection patterns. String concatenation in queries, unparameterized inputs. Claude flags these well even in ORMs with raw query escape hatches.
Exposed sensitive fields. API responses returning password hashes, internal IDs, or fields that shouldn't leave the server. Claude catches this when you show it the response serialization code.
Insecure cookie settings. Missing httpOnly, missing secure flag, missing sameSite. These are easy to forget and Claude reliably checks for them.
Hardcoded secrets. API keys, tokens, or passwords in source code. Claude flags these immediately.
What Claude misses or gets wrong
Business logic vulnerabilities. These require understanding your domain. An authorization check that's technically correct but logically flawed (a user can access another user's data through a valid API path) won't be caught without knowing the full data model and permission structure.
Race conditions. Time-of-check-to-time-of-use issues in concurrent code. Claude sometimes spots obvious ones but misses subtle cases.
Supply chain issues. What your dependencies do is outside Claude's review scope.
Use it as one layer, not the only layer
Claude security review → peer code review → security testing. In that order. Claude is fast and catches the common stuff. Peer review catches the domain-specific logic issues. Testing validates both.
Treating Claude's security review as the final word is the same mistake as treating any automated tool as the final word.