Vibe coding security risks: the checklist nobody runs

The whole appeal of vibe coding is that you don't read every line. You describe what you want, the model writes it, it works, you ship. Which is also exactly why the security holes get through — nobody looked.

AI code generators are good at making things work. They are far less careful about who else can reach the thing once it's live. These are the gaps that show up again and again in AI-built apps — and a checklist to close them before someone else finds them.

1. Secrets that shipped to the browser

The most common mistake is a private key in the wrong place — committed to the repo, or baked into the client-side bundle where anyone can open devtools and read it. A model wiring up an integration will happily drop the key wherever makes the code run.

Anything secret — a service key, a payment secret, a third-party API key — belongs in a server-side environment variable, never in code that reaches the browser. Public keys designed to be exposed are fine; the trouble is when a private one gets treated like a public one.

2. A database anyone can read

This is the big one for AI-built apps, because so many of them use Supabase with a public key in the frontend. That public anon key is only safe if Row Level Security is switched on and your policies actually restrict which rows each user can see.

Leave RLS off — an easy thing to overlook when the app "works" — and that public key lets anyone read and often write your entire database. Every user's email, every private record, straight out of the browser. It works perfectly right up until someone points a script at it.

3. Rules enforced only in the UI

Hiding an admin button from non-admins isn't access control — it's decoration. If the server doesn't re-check permissions on every mutation and sensitive read, anyone can call the endpoint directly and skip the UI entirely.

AI-generated code loves to guard actions in the frontend because that's where the click is. Every one of those checks needs a matching one on the server, where the user can't reach in and change it.

4. The rest of the usual gaps

• Unvalidated input. User input dropped straight into a query or a template opens the door to injection. Inputs get validated; queries get parameterised.
• Wide-open CORS. A permissive cross-origin policy generated to "just make it work" lets other sites call your API on a user's behalf.
• Leftover debug routes. Seed scripts, admin panels, and debug endpoints that were never meant for production, still reachable.
• Missing security headers and HTTPS. No HSTS, no clickjacking protection, mixed content, cookies without the Secure and HttpOnly flags — the defaults a generator rarely sets.

Two ways to actually check

The gaps split into two kinds. Some are visible from outside your app — headers, SSL, cookies, mixed content — and you can test those in seconds without touching the code:

The same hub has a SSL expiry check, a mixed-content checker, and a cookie security check — run all four on your live URL and you've covered the outside view.

The other kind — secrets, RLS, authorization — lives in the code, so the fastest audit is to turn the model on its own work. Paste this and make it check each item honestly:

Audit this app for the security gaps that AI code generators commonly leave in. Go through each item and tell me specifically whether my project is affected and how to fix it.

1. Secrets: are any API keys, tokens, or private keys committed to the repo or shipped in the client-side bundle? Which ones must move to server-side environment variables?
2. Database access control: if I'm using Supabase (or any Postgres-with-a-public-key setup), is Row Level Security enabled on every table, and do the policies actually restrict rows to the right user? Show me any table that's readable or writable with just the public anon key.
3. Authorization: is every mutation and sensitive read checked on the server, or is any of it enforced only in the UI where a user could bypass it?
4. Input validation: are inputs validated and queries parameterised, or is there any string-built SQL / unescaped user input?
5. CORS and exposed endpoints: is CORS scoped to my own origins, and are there any debug, admin, or seed routes still reachable in production?
6. Dependencies: are there known-vulnerable packages I should update?

For each finding, give me the exact file/line if you can see it, the risk in one sentence, and the fix.

Building specifically on Lovable? The RLS trap in particular shows up a lot there — we go host-specific in is Lovable secure?