Claude security audit
Built with Claude? Check these security risks before you ship.
Claude is excellent at scaffolding usable applications quickly. It is not optimized for safe defaults. Here are the recurring failure modes we see in Claude-built codebases — and what to do about each one.
Common problems
What we keep finding in Claude codebases.
Auth bypass
Claude often scaffolds auth flows that protect the UI, not the actual backend routes. The buttons disappear; the endpoints stay open.
ExampleUsers can’t see the admin button — butPOST /api/admin/delete-userstill works with any valid session.Secret exposure
API keys end up in frontend code, .env.example files committed to the repo, or client-side helpers Claude generated to keep things simple.
Broken file upload validation
Upload flows ship without MIME validation, extension validation, size limits, or storage isolation. The happy path works. The malicious path also works.
Prompt fixes
What to tell the model.
Paste these into your next conversation. They steer generation toward safer defaults — but they aren't a substitute for review.
For: Auth bypass
“Protect authorization at the API and database layer, not just frontend visibility. Validate user roles server-side for every sensitive action.”
For: Secret exposure
“Never expose secrets client-side. Move all privileged actions server-side and rotate any leaked credentials immediately.”
For: Broken file upload validation
“Validate uploads by MIME type, size, extension, and storage isolation. Prevent executable uploads and block direct public access to user-supplied files.”
Manual verification
The Claude checklist.
Run through each item by hand before you ship. If anything is unclear, treat it as a red flag, not a green light.
- Hit every admin endpoint with a non-admin session and confirm a 403.
- Search the client bundle for keys, tokens, and provider secrets.
- Upload an .html and a .exe disguised as .png — confirm they're rejected.
- Confirm role checks live in the API layer, not in the React tree.
- Verify rate limits exist on auth, password reset, and any expensive route.
If issues are already live
Damage control, in order.
If you suspect any of the above already shipped to real users, work the list top-to-bottom. Don’t skip rotation.
- 1Rotate every credential that has ever been in the repo or a client bundle.
- 2Invalidate all live sessions and force re-authentication.
- 3Pull access logs for the last 30 days and look for unauthorized admin calls.
- 4Test every admin and API route with an unauthenticated and a low-privilege session.
- 5Re-scan storage buckets for executable uploads and tighten ACLs.
Why AI-generated fixes still fail
The model that wrote the bug rarely sees it.
Same blind spots
The patterns that produced the vulnerability are baked into the model's training. Asking it to audit itself reproduces the same assumptions.
Context windows lie
The model sees the file you paste, not your auth middleware, your RLS policies, or the route you forgot to protect. It can't review what it can't see.
Confidence ≠ correctness
AI fixes look polished and read well. That's a signal of fluency, not of safety. Real verification needs a human who can hit the endpoint.
Don’t ask AI to audit AI
You wouldn’t let an intern grade their own homework.
Most builders type “is this secure?” back into the same chat that wrote the code. You need independent verification — someone whose context isn’t poisoned by what just got generated. That’s Kleared.
Most founders ask Claude to “fix security.” That usually creates more invisible risk.
Kleared manually verifies what the model misses, opens fix-PRs you can review, and signs a public badge once your repo is clean.
Before you launch
Run a real human security review.
Not another prompt. Kleared checks the boring stuff that breaks production:
- auth
- permissions
- secrets
- uploads
- database exposure
- API security
- payment flows
- production configs
So you can ship without guessing.