Guide

Lovable, Bolt, Replit and v0 app security checklist before launch

By Milo Kits · Updated 17 October 2026

Before you share an AI-built app, check six things: no secret keys in the frontend, database rules that stop strangers reading other people's data, real server-side checks on logins and admin pages, payments that the server (not the browser) controls, no stray files like .env on the live site, and basic security headers. Most of these take minutes to check and one prompt to fix. The checklist below covers apps built with Lovable, Bolt, Replit, v0, Cursor or Claude Code, whatever the backend (Supabase, Firebase or your own API).

AI coding tools are good at making things work, and less reliable at locking them down. Lovable itself now runs a security scan before publishing and says it blocks "around 1200 private API keys from being directly inserted in code per day" (Lovable blog). That figure is a good sign that this is a common mistake, and a reason to check for yourself.

1. Secrets: nothing private in the browser

Search your live JavaScript for sk- (OpenAI, Stripe secret), sk_live, service_role, sb_secret_, AKIA (AWS) and -----BEGIN (private keys).
Any env var starting with VITE_, NEXT_PUBLIC_ or REACT_APP_ ends up in the bundle. Only public-by-design values belong there. See our guide to keys in the frontend.
If a secret was ever public, rotate it. Deleting it from the code doesn't un-leak it.

2. Database: strangers can't read other people's rows

Supabase: RLS on for every table, with policies that match ownership. Details in Is my Supabase anon key exposed?
Firebase: no test-mode rules, no if true, no "any signed-in user can read everything". See Firebase rules mistakes.
Test logged out, then as a second user trying to open the first user's records.

3. Sign-in and roles: enforced on the server

Roles like "admin" or "pro" must come from the server or database, never from localStorage or a value the browser sends.
Every API route that reads or changes user data checks who's asking. Broken access control is number one on the OWASP Top 10.
Password reset and sign-up don't reveal whether an email has an account (nice to have).

4. Admin and debug pages: not just hidden

Open /admin, /dashboard, /debug and /api/admin/… in a private window. They should redirect to login or return 401/403.
Hiding a button isn't protection. Anyone can type the URL.

5. Payments: the server decides the price

Prices and plan IDs are looked up on the server, not taken from the request body.
Only the Stripe publishable key (pk_…) is in the frontend. The secret key (sk_…) stays on the server (Stripe: API keys).
Your webhook verifies Stripe's signature before trusting an event (Stripe: webhooks), and "upgrade" only happens from the webhook, not from a success page the user can visit directly.

6. Files, headers and HTTPS

/.env, /.git/config, /backup.zip and .map files return 404 on the live site.
HTTP redirects to HTTPS.
Security headers are set: CSP, HSTS, X-Content-Type-Options, Referrer-Policy and frame protection. Copy-paste configs are in Security headers for vibe-coded apps.

Copy-paste prompts for your AI coder

Whole-app review (run this first)

Act as a security reviewer for this app before launch. Check and report, with file paths: 1. Any secret (API keys, service_role / sb_secret_ keys, Stripe sk_ keys, private keys) that is reachable from client code or a VITE_ / NEXT_PUBLIC_ / REACT_APP_ env var. 2. Every database table or collection: who can read and write it when logged out, and whether one signed-in user can access another user's data. 3. Every API route and page that should require login or an admin role, and whether that check happens on the server. 4. Payment flows: is the price decided on the server, and does the webhook verify signatures? 5. Missing security headers and any debug routes, source maps or .env files in the production build. List findings as Fix first / Fix soon / Nice to have. Don't change code yet.

Server-side admin protection

/admin and /api/admin/* are only protected by hiding links in the UI. Please add a server-side check that the current user has an admin role (from the database or auth metadata, not localStorage) on every admin route and API, redirect non-admins away from /admin before it renders, return 403 from admin APIs for everyone else, and show me how to test it with a normal account.

Payments

Review my Stripe integration. Make sure: prices and plan IDs are chosen on the server from an allowlist (never from the request body), only the publishable key is in client code, the webhook verifies the Stripe signature with the signing secret, and a user's plan only changes in response to a verified webhook event. Show me the diff for anything that needs fixing.

After you fix things

Re-check after every big AI change. Tools can quietly undo a fix while "helping" with something else. A two-account test (user A, user B) is the single most useful habit.

FAQ

Are apps built with Lovable or Bolt secure by default?

They can be, but it depends on how the database rules, secrets and auth checks were generated and edited. Platform scans help, but they don't know your business logic, so you still need to check who can read which data, and make sure no secret keys reach the browser.

What's the most common security problem in vibe-coded apps?

Broken access control: database tables or API routes that let a logged-out visitor, or one user, read or change other users' data. Missing Supabase RLS policies and open Firebase rules are the classic examples, followed by secret API keys shipped in frontend JavaScript.

How long does a pre-launch security check take?

Working through this checklist yourself takes an afternoon for a typical small app. Most fixes are one prompt to your AI coder plus a quick re-test.

Do I need a penetration test before launch?

For a small app without sensitive data, a careful checklist like this one covers the most common problems. If you handle health, financial or other sensitive data, or significant payments, get a professional penetration test as well.

Can I ask my AI coding tool to secure the app for me?

Yes, and it's a good start: use the review prompt above. But verify the result yourself with logged-out and second-user tests, because AI tools can miss issues or report a fix that doesn't work.

Sources

This guide is general information, not a security audit. Platforms change, so check the linked docs for current details. Spotted something out of date? Email hello@milokits.com.