Security for vibe coders: the 7 things AI-generated apps leak first
Why vibe-coded apps leak
Shipping an app in a weekend with Cursor, Claude, Lovable, Bolt or v0 is genuinely amazing. But there is a catch that has nothing to do with the tools being bad: an AI writes the code that solves the problem you stated, and security is almost never stated. You ask for a working Stripe checkout, not for the key to stay server-side. You ask for a feature, not for a Content-Security-Policy.
The numbers back this up. Veracode found 45% of AI-generated code introduced a security flaw; a 2026 Checkmarx report put 65% of AI-built apps at one or more critical vulnerability. And automated bots scan every freshly deployed site for these mistakes — often within 15 minutes of going live.
Here are the seven that show up first.
1. API keys in the frontend bundle
The number one leak. A key for OpenAI, Anthropic, Stripe or AWS gets used in client-side code, and now it ships inside your JavaScript bundle for anyone to read. Secret in the variable name does not make it secret. Keys belong on the server, behind an endpoint — never in code the browser downloads.
2. An exposed .env file
The .env file is supposed to stay on the server. When it gets deployed into a public folder, anyone can request /.env and download your entire configuration — database URLs, tokens, the lot. One file, your whole stack.
3. Public source maps
Source maps (.js.map) are the debugging breadcrumbs that map your minified bundle back to your original, readable source. Helpful in development — but if they ship to production, you have effectively published your source code, comments and all. Strip them, or upload them privately to your error tracker.
4. Missing security headers
No Content-Security-Policy, or a permissive one with unsafe-inline, leaves the door open to cross-site scripting. Missing X-Frame-Options invites clickjacking. These are one-line fixes that frameworks do not add for you — and almost no vibe-coded app sets them by default.
5. Insecure cookies
A session cookie without HttpOnly can be read by any injected script. Without Secure it can travel over plain HTTP. Without SameSite it is exposed to cross-site request forgery. The defaults are rarely the safe ones, and a stolen session cookie is a logged-in attacker.
6. Internal URLs left in production
Debug code and build-time constants love to leave behind a localhost, a private 10.x IP, or a staging. hostname inside the served HTML or JS. Even when that host is unreachable from the internet, it hands an attacker a map of your internal services, ports and API shapes.
7. Outdated or compromised dependencies
The app you generated pulls in dozens of packages you never chose. Some are years past end-of-life; occasionally one gets hijacked outright — 2025 alone saw the qix compromise and the self-propagating Shai-Hulud worm hit packages with billions of weekly downloads. Pin your versions, commit your lockfile, and do not auto-run install scripts you do not trust.
Bonus: check your database rules
One more that bites vibe coders hard: open database rules. If you wired up Supabase or Firebase, make sure row-level security is actually on — a public table is a quiet, total data leak. Our scan focuses on what your website exposes, so verify this one directly in your backend console too.
Check your own app before a bot does
None of this means you should not ship fast. It means you should look before you do. Run your site through an automated scan, see which of these seven it leaks today, and fix them while it is still you finding them — not someone else.