Security Basics Every Vibe Coder Needs
AI-generated apps ship with predictable security holes. The five that actually get exploited — leaked keys, missing server-side checks, open databases, injection, and no rate limits — and the prompts that close them.
Key takeaways
- Never trust the client — every check must also happen on the server
- Secrets belong in environment variables; rotate any key that touches git
- Turn on row-level security before real users touch your database
- Ask your agent to audit its own code — it finds what it missed
Why AI-built apps get popped
AI agents write code that works in the demo. Security is precisely the stuff that doesn't show up in a demo — what happens when someone sends a request your UI would never send. Attackers know a wave of AI-built apps is live with default configurations, and they scan for them automatically. The good news: the same agent that created the holes can close them, if you ask.
1. Leaked API keys
The most common breach, and the most expensive when it's a pay-per-use AI key. Two rules cover it: secrets live only in environment variables (never in source files), and any key that was ever committed to git gets rotated, not deleted — history preserves it forever. Also make sure keys are only used in server-side code; anything in frontend code ships to every visitor's browser.
2. Client-side-only checks
Hiding the admin button doesn't protect the admin action — anyone can call your API directly with browser dev tools or curl. Every permission check, price calculation, and quota must be enforced in server code. This is the #1 logic hole in generated apps because the agent 'sees' the app through the UI, just like a polite user would.
Review every API route in this app. For each one, tell me:
1. What stops a logged-out user from calling it directly?
2. What stops user A from reading or editing user B's data?
Fix anything that relies on the frontend for enforcement.3. Open databases
Managed databases like Supabase are wonderful, but their client libraries talk to the database directly from the browser — which means the database's own rules are your security. Enable row-level security (RLS) on every table and write policies so users can only read and write their own rows. Supabase warns you about tables with RLS off; treat every warning as a fire.
4. Injection and unvalidated input
Any text a user submits should be treated as hostile: validated on the server, parameterized in database queries (never string-concatenated), and escaped when displayed. Modern frameworks and ORMs handle most of this by default — the danger zone is custom SQL and raw HTML rendering, both things agents occasionally reach for. A one-line prompt — 'check this app for injection risks and unsafe HTML rendering' — is cheap insurance.
5. No rate limits
Without rate limiting, one script can sign up ten thousand fake users, hammer your login with password guesses, or burn your entire AI API budget overnight. Ask your agent to add rate limiting to auth endpoints and anything that costs you money per call. If you're on Vercel, Cloudflare, or similar, much of this is a platform feature you just have to turn on.