The 5 Security Holes We Find in Almost Every Vibe-Coded App
When we review AI-generated codebases, we keep a running tally of what we find. The remarkable thing isn’t that the apps have security problems — all early software does. It’s that they have the same five problems, almost every time, regardless of which tool built them.
That consistency is actually good news. It means that if you built your app with Lovable, Bolt, v0, Replit, or Cursor, you can predict with high confidence where your risks are — and check them systematically. Here are the five, in the order of how often we see them.
1. Exposed API keys (found in roughly 4 out of 5 audits)
AI tools need your API keys to wire up integrations, and the path of least resistance is to paste them where the code can see them — which often means the frontend bundle that every visitor downloads. Your OpenAI key, your Stripe key, your database credentials: readable by anyone who presses F12.
The consequence isn’t hypothetical. Bots scan public sites for exposed keys continuously. An exposed OpenAI key typically gets found and abused within days, and you find out via a four-figure invoice.
The fix: every secret moves to server-side environment variables, every exposed key gets rotated (not just hidden — rotated, because it’s already compromised), and frontend code calls your own backend, which holds the keys.
2. Missing authorization checks
The app has login. The app has user accounts. And the app never checks whether the logged-in user is allowed to see the thing they’re requesting. Change the invoice ID in the URL from 1041 to 1042 and read someone else’s invoice. Call the delete endpoint on a record you don’t own, and it deletes.
This happens because AI tools generate features in isolation. Each feature works. The connective tissue — a consistent permission model applied everywhere — is exactly the kind of cross-cutting concern that prompt-by-prompt development never creates.
The fix is a single authorization layer that every request passes through, not per-page patches. This is usually days of work, and it’s the highest-severity item on this list: it’s the difference between a bug and a breach notification.
3. Client-side-only validation
The form won’t let you submit a negative price. But the API behind the form will accept one, because the only validation lives in the browser. Anyone with curl — or just browser dev tools — talks to your API directly, no form involved.
Beyond garbage data, this is how injection attacks happen: unvalidated input flowing into database queries or into prompts for your AI features (prompt injection is the new SQL injection, and vibe-coded AI apps are full of it).
The fix: validate everything on the server, treat the frontend validation as UX only. Schema validation libraries make this mechanical — once someone decides it needs to exist.
4. No rate limiting anywhere
Signup endpoints that accept unlimited requests become spam-account factories. Login endpoints without limits invite password-guessing. AI features without limits are the expensive one: each request costs you real money, and nothing stops a script from making a million of them.
The fix takes hours, not weeks: a rate-limiting middleware with sensible defaults, stricter limits on auth and paid-API endpoints. It’s the best security-per-hour investment on this list.
5. Overprivileged database access
The app connects to the database as an all-powerful admin, because that’s the connection string that worked during development. Combined with problem #3, this means an injection flaw doesn’t just leak one table — it owns the entire database. On Supabase specifically, we routinely find row-level security disabled or half-configured, which turns the client-facing API into a public database.
The fix: the app gets a database role with exactly the permissions it needs, and row-level security actually enforced. Test it by trying to read another user’s rows through the public API.
What to do with this list
If your app has real users or handles real data, check all five this week — in order, since that’s roughly their frequency and severity. Items one and four are fast fixes a competent developer handles in a day or two. Items two, three, and five need a systematic pass over the codebase.
If you’d rather know your exposure before deciding what to fix, that’s what our free Risk Audit and fixed-fee code audit are for. The audit report ranks findings by severity, in plain language, so you can make the call with real information. This is a sensitive area to get wrong quietly — most founders who get burned never saw it coming, because everything worked.
Free tool
How much risk is hiding in your AI-built app?
Ten questions, instant score across security, scalability, and maintainability — built from the checklist our engineers use in paid audits.