Vibe coding security is the set of checks an AI coding assistant never runs, because it answers "does it work" and never "is it safe to ship". Five things get left open: database rules, secret keys in the client bundle, routes with no auth check, debug output in production, and IDs a user can change to read someone else's row.
Why AI-built apps leak (the "it works so I shipped it" trap)
An AI coding assistant will happily generate a working feature without asking whether the feature is safe, because "does it work" and "is it secure" are different questions, and only the first one is visible when you click around your own app as an authenticated user. Permissive database rules, an unauthenticated endpoint, a key in the wrong file: all of these produce a fully working app for you and a fully exposed one for anyone who inspects a request or reads your rules.
This is not a knock on AI-generated code specifically, the same shortcuts happen in hand-written code under a deadline. Vibe-coded apps just tend to ship faster and get less manual review, so the gap between "works" and "safe" reaches production more often.
1. Database rules (Supabase RLS / Firebase)
The single most common leak: Row Level Security left off on a Supabase table, or Firestore rules still in test mode (allow read, write: if true). Either one means your entire dataset is readable, and often writable, by anyone with your public API endpoint, which ships in your client bundle regardless. Check this first; it is usually a five-minute fix and the highest-impact one on this list. Full walkthroughs: the Supabase security checklist and the Firebase rules checklist.
2. Secret keys in the client
Anything bundled into the browser is public: NEXT_PUBLIC_ variables, hardcoded strings, anything referenced from a client component. A secret key (Stripe's sk_, Supabase's service_role, any unlabeled third-party API key) has no business in that bundle. Search your built output for key-shaped strings before launch, not after. Details and a grep command in how to find exposed API keys.
3. Endpoints and admin routes with no auth
AI assistants generate route handlers and server actions readily, and will generate an /admin or /api/internal-* route just as readily, without adding an auth check unless you ask for one explicitly. Walk your own route list and confirm every route that touches user data or admin functionality actually checks who is calling it, not just that a request arrived.
4. Deploy hygiene (source maps, debug, stack traces)
Source maps deployed to production let anyone reconstruct readable source from your minified bundle, including any secret that got inlined at build time. Debug flags and verbose error pages left on in production hand out stack traces, internal paths, and sometimes query text to any visitor who triggers an error. Confirm both are off before your first real user hits the site. The same deploy config decides your response headers, and a missing Content-Security-Policy or Strict-Transport-Security is the same kind of default nobody got around to setting, so run your live URL through the security headers check while you are in there.
5. Auth and IDOR basics
Being logged in and being authorized are different checks. An endpoint that fetches /api/orders/:id without confirming the order belongs to the logged-in user is an IDOR (insecure direct object reference): change the id in the URL, read someone else's data. Every route that takes an id from the client should filter by the current user's ownership, not just require a valid session.
The 5-minute pre-launch pass
Before you ship: confirm database rules are not in test mode, grep your built bundle for secret key prefixes, list every route and confirm each checks auth, turn off source maps and debug output for the production build, and try changing an id in one authenticated request to see if it returns someone else's data. Five checks, most of them a single command or a single settings toggle, and together they catch the large majority of what actually gets found and reported after launch.