The top 5 security mistakes vibe coders make

I've looked at a lot of vibe-coded apps. The security issues cluster around the same five things — and they're not exotic. They're the boring, obvious stuff nobody thinks to check when they're shipping fast.

1. Exposed API keys in frontend code

This one's shockingly common. You paste your OpenAI or Stripe key directly into a .js file because it works and you just want to ship. It does work — until someone opens DevTools and finds it. Any key that ships with your frontend bundle is a public key. Treat it that way or don't use it there.

2. No rate limiting on your API routes

Your /api/scan endpoint has no cap on how many times someone can call it. A single person with a script can drain your credits, spam your database, or just knock your app offline. One middleware call fixes this. Most people skip it.

3. Supabase RLS turned off "just for now"

You turned off Row Level Security while debugging, shipped, and forgot. Now every authenticated user can query every row in your database. This is more common than you'd think — Supabase doesn't break when RLS is off, so there's no obvious sign anything is wrong.

4. Missing CSRF protection on forms

If your form submits to an API endpoint that only checks for a session cookie, another site can forge that request. Frameworks handle this automatically if you let them. The problem is when you bypass the framework to do something custom and forget to add it back.

5. Secrets in your git history

You added a .env file early on, committed it, then added it to .gitignore later. The key is gone from your working tree but it's still in every commit before that point. If the repo ever becomes public, tools like truffleHog find these in seconds.

None of this requires security expertise to fix. It requires someone to actually check.