AI Skills · 5 min read
12 Security Holes in Vibe-Coded Apps, and the One Prompt That Finds Them
You shipped your app in a weekend with Claude or Cursor. At least one of these twelve holes is probably live right now. Here is the full checklist, and the one prompt that makes Claude Code audit all of it for you.
"Key Takeaways"
- AI-generated apps ship fast and often ship with the same twelve security holes.
- The worst one is auth that only exists client-side: the UI hides the button, but the API answers anyone.
- Claude Code has a built-in /security-review command on every paid plan. It finds problems and offers to fix them.
- A 12-point prompt (included below) turns the whole checklist into one audit you run before deploy.
Summarize this article with
You shipped your app in a weekend with Claude or Cursor. Somewhere in that generated code, at least one of the twelve problems below is probably live right now. Each one is common and fixable in under an hour.
Hackers do not need genius for these. They need your defaults. Here is the checklist, then the prompt that runs it for you.
The 12 holes
- API keys in frontend code. Anything in client JavaScript is public: a viewer can open dev tools and read your OpenAI or Stripe key straight from the bundle. Keys belong on the server.
- A public .env file. AI scaffolds create them, and beginners deploy or commit them. If your .env ever reached a public repo or folder, treat every value in it as stolen.
- Secrets in git history. Deleting the file in a new commit does not remove it; the old commit still holds the key, and scanners crawl public history for exactly this. Rotate any key that was ever committed.
- Open database rules. Supabase without row-level security, Firebase with read and write set to true. The demo works because the database accepts everyone, including strangers with your project URL.
- Public storage buckets. User uploads and invoices sitting in an S3 or Supabase bucket that lists its contents to anyone. Check permissions before launch, not after someone tweets your customer files.
- No rate limits. One script can brute-force your login or drain your paid API quota overnight. Most platforms give you rate limiting in a few lines.
- Debug mode in production. Verbose logs, source maps, and framework debug pages tell an attacker how your app works inside. Turn it off in the production build.
- Admin routes without auth. /admin deployed on the hope nobody finds it. Crawlers find it in minutes. Every admin route needs a server-side permission check.
- SQL injection. Raw queries built from user input still work in 2026, and AI-generated code produces them when you ask for a quick search feature. Use parameterized queries or an ORM.
- Passwords in plain text. If your database leaks and passwords are readable, the damage spreads to every site where users reused them. Hash with bcrypt or argon2.
- Stack traces shown to users. Error pages that print file paths and table names hand over a map of your system. Show users a plain error; keep the trace in your logs.
- Auth that only exists client-side. The worst and most common. The UI hides the dashboard button, but the API behind it answers anyone. Every protected endpoint must verify the user on the server.
Run the audit instead of memorizing it
- Install Claude Code once: npm install -g @anthropic-ai/claude-code
- Open your project folder in the terminal and type: claude
- Type /security-review. It is built in (Anthropic shipped it in August 2025, available on every paid plan). It scans for injection, auth flaws, and exposed secrets, then offers to fix what it finds.
The 12-point prompt
Paste this after /security-review, or on its own:
Audit this codebase against these 12 vibe-coding security holes. For each: PASS or FAIL, the file and line if FAIL, and the fix. 1) API keys or secrets in frontend or client JS 2) .env or config files exposed publicly or committed 3) secrets anywhere in git history 4) overly permissive database rules (Supabase or Firebase RLS off, world-readable) 5) public storage buckets (S3, Firebase, Supabase) 6) missing rate limiting on APIs and auth 7) debug mode or dev tools enabled in production 8) admin routes reachable without auth 9) SQL or NoSQL injection via unsanitized input 10) passwords stored in plain text or with weak hashing 11) stack traces or internal errors shown to users 12) auth checks that only exist client-side. End with the three highest-risk fixes first.
Two honest notes
If the audit finds a key in git history, rotating the key at the provider is the fix. Cleaning history is optional afterwards.
This complements a real security review rather than replacing one. It catches the classics that sink weekend launches, which is the point.
Make it run on every pull request
Anthropic also publishes a GitHub Action (anthropics/claude-code-security-review) that runs the same review on each pull request and comments findings inline. Add it once and new code gets checked before merge.
You can customize the checks by copying security-review.md into your repo's .claude/commands folder and editing the list, so the 12-point prompt above can become your team's standing command.
Quick questions
Does /security-review cost extra?
No. It ships inside Claude Code and works on every paid Claude plan and for API users. You pay only the normal usage of the plan you already have.
I already leaked a key. Is deleting the file enough?
No. The key stays in git history and scrapers look for exactly that. Rotate the key at the provider (OpenAI, Stripe, Supabase), then update your server config with the new one.
Will it fix the problems or just list them?
Both. It reports findings first, and you can tell it to apply the fixes. Review the diff before you accept, the same as you would for any code change.
The Chai Takeaway
Shipping fast is fine. Shipping with defaults is what burns people. Run the audit once before your next deploy: the checklist takes 25 seconds to read, and the audit usually finishes before your chai does.
Explore More AI Skills