The Security Checklist Every AI-Generated Codebase Fails First
We audit AI-built codebases for a living — it’s our Rescue service — and the findings are monotonous in the way that matters: the same seven failures, in roughly the same order, in almost every unreviewed AI-generated app. Here’s the checklist, with the reasoning, so you can run a first pass on your own prototype tonight.
The context for urgency: the Cloud Security Alliance puts security vulnerabilities in more than 60% of AI-generated code, and an independent May 2025 audit found ~10% of apps on one popular AI builder leaking sensitive user data in production. (If you’re deciding whether to keep building solo, start with the vibe-coding decision guide.)
1. Secrets in the code
The #1 finding, every time. API keys, database URLs, and payment secrets hardcoded in the repo or shipped to the browser bundle. Automated scrapers watch public deploys — in one documented case, exposed AWS keys were found and exploited within 12 minutes, running up $50,000+ in compute.
Check: search your codebase for sk_, key, secret, password. Anything real belongs in environment variables on the server — never in frontend code, never in git history.
2. Missing authorization (not authentication)
AI tools implement authentication (who are you?) reasonably well, and almost universally forget authorization (are you allowed?). The result: any logged-in user can read or modify any other user’s data by editing an ID in the URL or API call.
Check: log in as user A, take an API request, replace the record ID with one belonging to user B. If it works, every row in your database is public to your users.
3. Trusting the client
Prices calculated in the browser and sent to the server. Role flags (isAdmin: true) accepted from the request body. Hidden buttons treated as security. AI-generated frontends are full of decisions the server should make.
Check: can you change what you pay, or what you’re allowed to do, by editing the request in browser dev tools?
4. Payment flows with only a happy path
The demo shows a successful charge. Production contains declined cards, disputes, double-clicks, webhooks arriving twice or never, and refunds. Unreviewed AI code handles almost none of it — the money still moves, the database doesn’t notice.
Check: use a test card that declines. Does your app end up in a coherent state?
5. No input validation or rate limiting
Forms that accept 10MB of text, endpoints that accept a million requests, uploads with no type checks. Individually small; combined, they’re your outage (or your injection vector).
Check: what happens when a signup endpoint gets hit 1,000 times in a minute?
6. Injection via string-building
Modern frameworks protect against SQL injection by default, but AI code that drops to raw queries, shell commands, or HTML string concatenation reintroduces the classics. LLM-powered features add a new one — prompt injection through user content that reaches your model calls.
Check: grep for raw SQL string interpolation, eval, and user input concatenated into anything executable — including prompts.
7. Zero observability
Not a vulnerability — the thing that turns vulnerabilities into catastrophes. No error monitoring, no alerts, no audit logs: you learn about the breach from a customer, weeks later.
Check: if an exception was thrown in production right now, would anything tell you?
Passing this list is table stakes, not paranoia
This checklist is roughly what our hardening pass covers in the final week of every build — plus automated tests on every push and the audit trail we hand over at ship. It’s why “built with AI” doesn’t have to mean “built like a prototype.”
If you’d rather not run the checks alone: our 3-day Rescue audit does all seven properly, ranked by severity, with a written fix roadmap — $1,500, credited toward a rebuild if you want one. Cheaper than 12 minutes of someone else’s AWS bill.
