The Vibe Coder's Pre-Launch Security Checklist

Shipping an AI-built app? These are the security risks vibe coding misses, plus a pre-launch checklist to fix them before strangers find them.

By Artem Vysotskyi · Updated

AI-generated apps ship fast, and the things that get skipped are the ones that do not break the demo: database rules left open, secret keys sitting in client code, admin routes with no auth check, debug output still on in production. None of it shows up while you are testing your own app as yourself. This is the short list of checks that catches most of what strangers find first.

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.

Run the 30-second scan before you launch

FAQ

Is a vibe-coded app safe to launch?

It can be, the AI-generated part is not inherently less secure than hand-written code, but it is rarely reviewed with security in mind by default. Running through this checklist before launch, rather than after someone finds a problem, is what makes the difference.

What is the most common security bug in AI-built apps?

Database rules left open: Supabase tables with RLS disabled, or Firestore and Storage still in test mode. It is the default state of a fresh project, it is invisible while you test as yourself, and it exposes the entire dataset at once rather than one field or endpoint at a time.

Do I need a full security audit?

Not necessarily before a first launch. A full audit is worth it once you have real users and real data at stake. Before that, this checklist covers the handful of issues that account for most real-world leaks in early-stage apps, and takes minutes rather than days.

How do I check my app quickly?

Run through the five checks above manually, or run an automated scan against your live URL to catch open database rules, exposed keys, and other common misconfigurations without reviewing every file by hand.

Find out in 30 seconds

Paste your URL and LeakRank shows what a stranger can actually read from your app. Free, no signup.

Scan my app free →

Related guides