Claude Code Security Review for Client Work: The Pre-Handoff Pass That Protects Your Reputation
- A security review is a dedicated pass, separate from building, where Claude Code reads the finished work cold and hunts for a short list of expensive mistakes: secrets committed to the repo, endpoints anyone on the internet can call, unvalidated input, and paid API keys sitting behind doors with no lock.
- Run it in a fresh session that did not write the code, from a written checklist, and fix what it finds before the client ever sees the build. The session that built the feature is the worst candidate to audit it, because it reviews its own assumptions.
- Name the pass in your proposal and your handoff email. 'Security review completed' is one line that raises the perceived value of the whole build, justifies your price, and separates you from every builder who ships whatever ran first.
What a Security Review Pass Actually Is
A security review is a read-only pass over a finished build where the only job is finding ways the work can hurt the client: leaked credentials, endpoints with no authentication, user input that reaches a database or a shell unchecked, and paid API keys that anyone with the URL could burn. It is not a rebuild and it is not a refactor. It is a hunt, run from a checklist, that ends in a short list of findings and fixes.
Claude Code makes this cheap to run. The desktop app ships a built-in security review command that scans the project for common vulnerability patterns, and even without the command, a fresh session pointed at the repo with a tight review brief will surface most of the same issues. The cost of the pass is an hour at the end of the build. The cost of skipping it is the phone call where a client asks why their API bill exploded or their customer data was sitting in a public repo.
The Checklist: What to Hunt For Before Handoff
Do not ask the session to 'check security' - vague briefs produce vague reviews. Give it a named list of the failure modes that actually end client relationships, and make it walk the codebase against each one.
- Secrets in the repo: API keys, database passwords, and tokens hard-coded in source files or committed in env files. Every one of these should live in environment configuration the client controls, never in the code you hand over.
- Unprotected spend: any endpoint that holds or calls a paid API key is a place someone else can spend the client's money. It needs authentication, an origin allowlist rather than a wide-open CORS policy, and rate limiting before it goes live - no exceptions, not even for a demo.
- Missing auth on private routes: admin pages, data exports, and webhook handlers that assume nobody will find the URL. Assume everyone finds the URL.
- Unvalidated input: anywhere user-supplied text reaches a database query, a file path, or a shell command without being checked. This is the classic injection family, and it hides in the boring corners - search boxes, file uploads, contact forms.
- Over-broad permissions: database roles, API scopes, and service accounts that can do far more than the feature needs. Tighten each one to the minimum that keeps the build working.
- Client data in logs: personal information echoed into log files or error messages that will outlive the debugging session that created them.
This list pairs with the data-handling habits you should already be running during the build - [keeping client data safe inside Claude Code sessions](/blog/is-it-safe-to-use-claude-code-with-client-data) is the during-the-build discipline, and the security review is the end-of-build gate that catches whatever slipped through.
How to Run the Pass So It Actually Catches Things
The single most important rule: the session that wrote the code does not review the code. A session carries its own assumptions - it believed the endpoint was internal when it built it, so it will believe the endpoint is internal when it reviews it. Open a fresh session on the same folder, hand it the checklist, and let it read the work cold. This is the same fresh-eyes principle behind [splitting building from checking with a subagent workflow](/blog/claude-code-subagent-workflow-for-client-work), applied to the highest-stakes review you run.
- Finish the build and commit it, so the review runs against exactly what the client will receive.
- Open a fresh Claude Code session on the project folder and run the built-in security review command, or paste your checklist as the brief: 'Read this codebase and report findings against each item. Do not fix anything yet.'
- Read every finding yourself and sort them: real issues to fix now, hardening worth proposing as follow-up work, and false alarms to dismiss. You make the calls - the agent hunts, you judge.
- Fix the real issues in your normal build session, then run the review once more to confirm the list comes back clean.
- Record the date, the scope, and the outcome in a short note. That note becomes a line in your handoff and proof of professional care if anything is ever questioned.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Does Claude Code have a built-in security review?
Yes. The desktop app ships a security review command that scans the current project for common vulnerability patterns like injection risks, authentication gaps, and mishandled secrets, and reports what it finds. Treat it as the starting point rather than the whole job: run it in a fresh session, add your own checklist for the risks specific to the build - especially anything that can spend the client's money - and judge every finding yourself before deciding what to fix.
When should I run a security review on a client build?
At minimum, once at the end of the build, after the work is committed and before the client sees it - that is the gate that protects the handoff. Add a mid-build pass on longer projects so a structural issue surfaces while it is still cheap to fix, and re-run the review after any change that touches authentication, payments, file uploads, or a third-party API key. If the client is on a maintenance plan, a periodic re-review is a natural recurring line item.
Why should a different session review the code instead of the one that built it?
Because a session inherits the assumptions of the conversation that built the feature. If it believed an endpoint was internal-only while writing it, it will keep believing that while reviewing it, and the gap sails through. A fresh session reads the code as it actually is, with no memory of what was intended. Opening a new session on the same project folder costs nothing and is the closest thing to a second pair of eyes a solo builder has.
What are the most common security issues in AI builds for clients?
The repeat offenders are unglamorous: API keys and passwords committed into the repo instead of environment configuration, endpoints that call paid APIs with no authentication or rate limiting in front of them, admin routes protected only by an unguessable URL, user input passed into queries or commands without validation, and personal data left sitting in logs. None of these require a sophisticated attacker to exploit - most just require someone to notice. That is why a checklist pass catches so much.
Can I charge clients for a security review?
Yes, and you should name it either way. On a full build, include 'security review before handoff' as a listed step in the proposal - it justifies your price and signals professional process. As a standalone offer, an audit of an existing system someone else built is a strong small first engagement: fixed scope, fast turnaround, and it naturally leads to the fix work and a maintenance relationship. Just sell it honestly - a documented set of checks run on a date, not a guarantee of invulnerability.
Last reviewed September 21, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
