Vibe coding means describing what you want to an AI tool and accepting the code it produces, often without reading it line by line. It has made shipping a working prototype a matter of hours. The catch is that "working" and "safe" are different tests, and AI tools optimise for the first. The good news is that the security mistakes are repetitive, so a checklist catches most of them.
The 12 most common security holes in AI-generated apps
| # | Risk | What it looks like | Fix |
|---|---|---|---|
| 1 | Secrets in the client | API keys for OpenAI, Stripe or a database admin key bundled into front-end JavaScript | Move calls server-side, rotate the exposed key |
| 2 | Missing server-side authorization | The UI hides other users' records, but /api/orders/123 returns anyone's order (IDOR) | Check ownership on every endpoint |
| 3 | Database row-level security off | Supabase/Firebase tables readable with the public anon key | Enable RLS and write policies per table |
| 4 | Permissive CORS | Access-Control-Allow-Origin reflects any origin with credentials | Explicit origin allow-list |
| 5 | Injection | SQL built with string concatenation, eval on user input | Parameterised queries, no eval |
| 6 | Unsafe HTML rendering | innerHTML / dangerouslySetInnerHTML with user content | Framework escaping, a sanitiser, a CSP |
| 7 | Hallucinated or outdated packages | A suggested dependency that does not exist (or is a typo-squat), or a 2019 version | Verify every new package, enable dependency alerts |
| 8 | No rate limiting | Login, sign-up, AI and email endpoints callable thousands of times a minute | Per-IP and per-account limits |
| 9 | Verbose errors | Stack traces and SQL errors returned to the browser | Global error handler, generic messages |
| 10 | Weak session handling | JWTs in localStorage, no expiry, cookies without Secure/HttpOnly | Short-lived tokens, secure cookies |
| 11 | Unrestricted file upload | Any file type and size, stored in a public bucket under its original name | Type and size checks, random names, private storage |
| 12 | Missing security headers | No HSTS, CSP, frame or nosniff headers on the deployed site | Add at the host or CDN |
Why AI tools make these mistakes
- They solve the prompt you wrote. "Show the user their orders" gets a filtered UI query, not an authorization rule, unless you ask for one.
- They learned from public code, including tutorials that skip security for brevity.
- They lack the full picture. A model editing one file cannot see that another endpoint exposes the same data.
- They suggest packages from memory, which may be outdated or not exist at all. Attackers now register commonly hallucinated package names ("slopsquatting").
The pre-launch checklist
- Search the built front-end bundle for
sk-,key,secret,service_roleandpassword. Anything found is already public, so rotate it. - For every API route, write down who may call it and which records they may touch, then test it with a second user account.
- Turn on row-level security and run your app as an anonymous user against the database API.
- Run
npm audit/pip-audit/dotnet list package --vulnerableand open each new dependency's registry page to confirm it is the real one. - Add rate limits to authentication, AI, email and payment endpoints.
- Remove debug output and check that errors return generic messages.
- Scan the deployed site with the free ZetsApp Website Security Audit for HTTPS, headers, cookies, CORS and vulnerable libraries, and fix everything marked failed.
- Ask the AI to review its own code with a security-focused prompt and have a human read the auth and data-access code. Use both, not either.
Prompts that produce safer code
Add standing instructions to your AI tool's project rules:
- Every API endpoint must verify the caller is authenticated AND owns the requested record.
- Never put secrets in client-side code; read them from server environment variables.
- Use parameterised queries only; never build SQL with string concatenation.
- Never use eval, new Function or innerHTML with user input.
- Only use well-known, maintained packages; state the exact version.
- Add rate limiting to auth and any endpoint that sends email, SMS or calls a paid API.When to bring in engineers
A vibe-coded prototype is a great way to validate an idea. Before it handles payments, health data, children's data or business-critical records, it needs a proper security review and usually some re-architecture. ZetsApp turns prototypes into production systems through MVP development and custom software development, with security review included. See also our guide to the OWASP Top 10:2025.
Frequently asked questions
Is vibe coding secure?
It can be, but not by default. AI coding tools reliably produce working features and frequently miss server-side authorization, secret handling, rate limiting and secure configuration. A structured review before launch closes most of the gaps.
What is the biggest security risk in AI-generated code?
Missing server-side authorization (insecure direct object references) and secrets exposed in client code are the most common serious issues, because the app appears to work correctly in normal use.
What is slopsquatting?
An attack where criminals publish malicious packages under names that AI models commonly hallucinate, so developers who install a suggested dependency without checking it pull in malware.
How do I security-test an app built with Lovable, Bolt or Cursor?
Search the client bundle for secrets, test every API with a second user account, enable database row-level security, audit dependencies, add rate limits, and scan the deployed site's headers, TLS and cookies with a tool like the ZetsApp Website Security Audit.
