Checklist

Pre-launch security checklist for AI-generated code

Short answer. Read the generated client for secrets, and read the database rules for anything a second user can open. A working preview only shows that the happy path runs. Lovable, Bolt, Supabase, and Firebase each document a version of that gap, and each says their own checks are not a guarantee.

Updated 19 Oct 2026

This is a practical checklist, not a guarantee. It is not a penetration test, a compliance audit, or proof that an app is safe to launch.

The pre-launch security checklist is the pass over the running app: URLs, accounts, payments, and abuse. This page is the pass over the code an AI tool wrote. Use both. Neither one is a penetration test.

Builders covered here are Lovable, Bolt.new, and the same class of output from Cursor, v0, and Replit. The per-builder notes are Ship a Lovable app and Ship a Bolt app.

What the model tends to ship

These are patterns the vendors document, not a statistic about how often they appear.

What you may find in the project	What to verify	Where that warning comes from
A key next to a `fetch` in the client	It is a publishable value, or it moves to a server secret	Lovable's security overview, Supabase's API key docs, Firebase's API key docs
A new table with no access policy	Row level security or Security Rules exist, and a second user fails	Supabase's RLS docs, Firebase's insecure-rules guide, Bolt's database security page
A rule that only checks "is signed in"	The rule also checks which rows that person owns	Firebase's rules guide on `auth != null`
A price, a plan, or a "paid" flag set in the browser	The server hears the result from the payment provider	Lovable's Deep scan description of payments
An admin or service credential in client code	The credential is only in a server function	Supabase's secret-key docs and Bolt's project audit

Secrets the browser can see

Search the repository and the built JavaScript.

Supabase's docs say the publishable key may be in the client, and the secret key bypasses Row Level Security. Older service_role keys are in the same class. Supabase says those legacy names are being deprecated by the end of 2026.
Firebase's docs say an API key restricted to Firebase services is public by design. A key whose allowlist includes a non-Firebase API, such as the Gemini Developer API, is not that kind of key.
Lovable says values prefixed with VITE_ are browser values and belong in .env. Secrets belong in the Secrets store, which Edge Functions read.
Bolt says its project audit looks for private keys in the project code or in the browser, and its secrets tab exists so server functions can hold them.

The procedure is the API key checklist. Rotate a real secret at the vendor, then remove it from the client. The code and dependency security category is for tools that read the repo once it is in git.

Data rules, not the sign-in screen

Generate a second user. Request the first user's data with the same client the app uses. Then try with no user.

On Supabase, including Lovable Cloud's Supabase-style keys, follow the row level security checklist. Supabase's docs say grants and policies are separate. A new table in public on an existing project can already grant read and write to the anonymous and signed-in roles. A policy does not revoke a grant.
On Firebase, open Security Rules. Test mode grants access to all users. Locked mode denies client access. A rule of auth != null still lets any signed-in user through, which Firebase's rules docs say you should confirm you intend. Firebase is the directory entry.
On Bolt's database, the security page is available on every plan and flags a missing or always-open policy. Bolt says a table without row level security can be read and changed by anyone. The full project audit is a paid-plan check. Details are in how to secure a Bolt.new app.

The database and auth category lists the products. The auth comparison is Clerk vs Supabase Auth vs Auth0. Login and authorization are separate.

Money, mail, and routes anyone can call

A generated checkout often ends in a screen that says the payment worked. Lovable's Deep scan looks for prices or paid features a customer can change or reach without paying. Bolt's paid project audit says it looks for the same class of misuse. The check you can do yourself is the Stripe webhook checklist when Stripe is the provider: the server verifies the signature. Browse payments for the other checkout tools.

Password resets and receipts go out through an email API held on the server. A route that calls a model or sends mail needs a rate limit on that server. Disabling the button while a request is in flight is a UI state.

After you have read the code

Run one product from security scanners against the URL you will share, if you are allowed to scan it. Lovable's security overview and this directory use the same boundary: a scan supports a review and does not replace one.
Know which URL is production. Lovable's preview shares its database with the published app. Vercel, Netlify, and Render preview behavior is compared in Vercel vs Netlify vs Render.
Turn on something from monitoring so the first failure is an error report.

FAQ

Is this the same checklist as the pre-launch security checklist?

No. That checklist walks the running app: hosts, accounts, webhooks, and abuse limits. This one walks the generated source and the data rules. Finish with both. The other page is the pre-launch security checklist.

Does a green scan from the builder mean the app is safe?

No. Lovable's security overview says its scans help find common issues and cannot guarantee complete security. Bolt's project audit reports what it checked and what it fixed. A clear result means that pass found nothing it reports. It does not mean a later change, or a case the scanner skips, is fine.

What is the first thing to open in a Lovable or Bolt project?

The data rules. Lovable's Quick scan, which runs when you open Publish, checks database access, dependencies, and exposed MCP servers. Bolt's database security page is on every plan. Then search the client for a secret key. The longer Lovable steps are in how to secure a Lovable app before launch.

Which host should this code deploy to?

The one the project already uses, until you choose to export it. If you are picking a host for a repo you own, start with Vercel vs Netlify vs Render for AI-built apps and the hosting category. The host is where environment variables live. It does not write your database policies.

Sources

Checked 19 Oct 2026.

A short weekly note on new tools and security checklists. No spam, unsubscribe anytime.