The vibe-coding security checklist: 7 checks before you launch

Before you share the link

AI coding tools get you to 'it works' fast, and skip 'it's safe' silently. This is the short list to run before real people (and the bots that crawl every new app) get their hands on it. None of it requires being a security expert — just going down the list.

The 7 checks

1. No secret keys in the browser. Search your live app's JavaScript for 'sk_live', 'sk-', 'AKIA', and 'service_role'. Secret keys belong on the server only; publishable keys (pk_live, anon) are fine.

2. Database access rules are on. Supabase tables need Row Level Security with real policies; Firebase needs rules that aren't in test mode. Without them, your public key can read everyone's data.

3. The service_role / admin key is server-only. The Supabase service_role key bypasses every rule — if it's anywhere in your client code, treat your whole database as compromised and rotate it.

4. Authentication and authorization run on the server. Who's logged in, what plan they're on, whether they're an admin — all decided server-side, never trusted from the browser.

5. Prices and entitlements aren't set by the client. Don't let the browser tell your server what to charge or what to unlock. Confirm payments with your provider server-side.

6. Secrets live in environment variables, not in code. And not behind a public prefix like NEXT_PUBLIC_. Rotate anything that was ever committed or shipped to the client.

7. You actually tested it logged out. Open your app in a private window, signed out, and try to reach data you shouldn't. Getting nothing back is the goal.

Run checks 1–3 automatically

The first three — the highest-impact, most common leaks — are exactly what VibeShield checks for. Paste your live app's URL and it reads the public files any visitor's browser already downloads, then flags exposed secret keys and detectable open-backend setups with a plain-English fix for each.

Checks 4–7 are server-side logic an outside scan can't fully see, so treat those as your manual pass. Work the whole list once before launch, and re-scan after any big change.

Frequently asked questions

I'm not technical — can I really do this checklist?

Yes. The riskiest items (exposed keys, open databases) can be checked automatically with a scan, and the rest are yes/no questions about how your app makes decisions. You don't need to read all the code to get through the list.

How often should I re-run this?

Before your first launch, and again after any change that touches auth, payments, the database, or a new integration — those are exactly the moments a new leak gets introduced.