6 Security Mistakes Almost Every Vibe-Coded App Makes

Last month I went back through one of my older projects and did a full security pass on it, specifically looking for holes that AI coding assistants tend to leave behind. I found more than I expected.

If you've built an app recently by describing what you want and letting an AI assistant write most of the code, there's a good chance a few of these are sitting in your codebase right now. None of them are hard to fix once you know to look for them. The problem is that AI tools are optimized to generate code that works, not code that's secure, and those are two different bars.

Here's what to check.

1. API keys in client-side code

If your AI assistant dropped a secret key directly into a React component, or into a .env file that never made it into .gitignore, that key is exposed the moment you deploy. Anyone can open dev tools or your public repo and grab it.

Fix: any call that needs a secret key should go through a server-side function, never the client. The browser should never see a key that isn't explicitly meant to be public.

2. No rate limiting on API routes

Rate limiting almost never shows up by default in AI-generated code, because nobody asked for it explicitly. Without it, your API routes are wide open to being spammed, which can run up your AI or infrastructure bill fast, or make brute-forcing logins trivial.

Fix: add basic rate limiting to any public-facing route, especially auth and anything that calls a paid API on the backend.

3. Auth checks that only exist on the frontend

AI assistants are great at hiding a button when you're not logged in. They're much less consistent about verifying the session again on the server. If the check only lives in the UI, anyone can call your API directly and skip the frontend entirely.

Fix: every protected route needs its own server-side session check. Never trust the frontend to be the only gate.

4. Stripe webhooks with no signature verification

If your webhook handler isn't verifying the signature on incoming events, anyone who finds the endpoint can send a fake "payment succeeded" payload and get free access to your product.

Fix: always verify the webhook signature against your Stripe secret before trusting the payload.

5. Database rows with no row-level security

This one shows up constantly with Supabase projects. Without RLS policies in place, a logged-in user can sometimes read another user's data just by changing an ID in the request, no exploit required, just a modified query.

Fix: set up row-level security policies as part of your initial database setup, not as an afterthought once you have real users.

6. Admin routes protected by "nobody knows the URL"

This is more common than it should be. An admin panel with no auth check, just a URL nobody's supposed to guess, is not a security model. It's a matter of time.

Fix: treat admin routes with at least the same auth rigor as customer-facing ones, ideally more.

Why this keeps happening

None of these mistakes are new or unique to AI-assisted development. They're the same issues developers have shipped since long before any of this tooling existed. What's changed is speed: AI tools let you go from idea to a working deploy in hours, which means the manual review step people used to naturally build in gets skipped entirely. The code runs, it looks done, so it ships.

The fix isn't to slow down your build process. It's to have a checklist you run through before anything hits production, regardless of how it got written.