Vibe coding security checklist: 10 checks before you launch an AI-built app

AI app builders write working code quickly, and working isn't the same as safe. A login page that lets you in proves the happy path; it says nothing about what a logged-out visitor can do with your database's public API. This checklist is for apps built with Lovable, Bolt, Base44, Replit Agent, v0 or a coding agent, and every item points to a real, sourced incident or vendor document. We haven't pen-tested these platforms ourselves; this is a reading of public research and vendor docs, checked November 1, 2026.

What has actually gone wrong

The pattern is consistent. The code worked in the demo, the platform's defaults didn't stop it, and the failure was in access control: who can read what, and who can call what.

The checklist

1. Row-level security is on for every table.

   If your app uses Supabase (Lovable Cloud does underneath, and Bolt and others offer it), the browser talks to the database directly with a public key. Supabase's own docs are blunt: "Enable RLS on every table in an exposed schema," because a table without it "is readable and writable by any role with a grant on it" (Supabase RLS docs). Open the table list in your database dashboard and confirm RLS is on for every one, including the ones the AI added last week.

2. The policies actually separate users.

   RLS on with a policy of "anyone can read" is the same as RLS off. Make two test accounts. Log in as A, create a record, then log in as B and try to see, edit and delete it, through the app and by calling the API with B's session. Then try it logged out. A scanner can tell you RLS exists; only a test tells you the policy is right.

3. No secret key is in the browser.

   The secret or service_role key bypasses RLS entirely; Supabase says "Never use a secret key in the browser." Escape found service keys retrievable from front-end bundles in its scan. Open your live site, view the page source and the loaded JavaScript in developer tools, and search for service_role, secret, sk_ and your payment and email providers' key prefixes. Anything found must move to a server function, and the key must be rotated, because it's already public.

4. Every server function checks who's calling.

   Edge functions and API routes run with more power than the browser. Each one should verify the user's session and their right to the specific record, and reject everything else. The February 2026 incident shows why reading isn't enough: the check existed, but it was inverted. Call each function logged out and as the wrong user, and confirm you get an error.

5. "Private" means authenticated, not hidden.

   An unlisted URL or an internal app ID isn't a lock. In the Base44 case the app_id sat in the URL, and it was all an attacker needed. If an app is for your team only, restrict sign-up to an allowlist or your company's domain and require login on every page and every API call.

6. Storage buckets are private unless they must be public.

   Uploaded files (IDs, invoices, photos) belong in private buckets served through short-lived signed URLs. Check each bucket's setting, then paste a file's direct URL into a logged-out browser window.

7. Production data has a backup you've restored once.

   Know where your backups are, how far back they go, and how to restore. Replit Core keeps 7 days of database restore and Pro 28; other platforms differ. Do one test restore before launch, while it doesn't matter.

8. The AI agent can't touch production.

   A "code freeze" typed into a chat is an instruction, not a permission, and in the SaaStr case the agent ignored it. Keep separate development and production databases, give the agent the development one, and make production changes through a reviewed deploy. If you connect agents to outside systems, the same rule applies; see how to vet an MCP server.

9. Anything that costs money or sends messages is rate-limited.

   Sign-up, password reset, email and SMS sending, and any endpoint that calls an AI model can be abused at scale: the February 2026 app let anonymous users send bulk email. Add per-user and per-IP limits, and a spending cap on your AI provider account.

10. You ran the platform's scanner and fixed what it found.

    Lovable says every project includes a free security scan before publishing and that "it is at the discretion of the user to implement these recommendations." Run whatever your platform offers, fix every high finding, and then do checks 2 and 4 by hand anyway, because scanners miss logic errors.

Who owns which risk

Platforms fix platform flaws; you own your app's access rules. That split shows in the record. Base44's auth bypass was the platform's, and Wix fixed it in a day. The RLS failures and the inverted check lived in individual customers' apps, and Lovable's position on the CVE is that each customer is responsible for protecting their data. Whatever you think of that position, it's the one you're operating under.

When to get help

If the app holds payments, health records, children's data or anything regulated, have someone who didn't build it review it before launch, and keep the code in your own repository so they can. If you've outgrown the builder, a coding agent in your own repo makes those reviews easier; the AI app builders comparison covers when to make that move, and the build-cost calculator helps you price the builder you're on.