Security checklist for Lovable, Bolt, Cursor and v0 apps

AI app builders are very good at making things work. They are not built to make sure things only work for the right person. That gap is where most real-world leaks come from: a table any visitor can read, a paid API key in the browser, a backup file left on the server.

Public research shows how common this is. A June 2026 scan of 1,072 Supabase-backed vibe-coded apps found 98% had at least one security issue, and Escape's October 2025 study found 400+ exposed secrets across 5,600+ public apps.

This checklist is ordered by impact. The first five cover most of what actually goes wrong.

1. No secret key in the frontend

Paid API keys (OpenAI, Anthropic, Stripe secret keys), database URLs with passwords and your Supabase service role key must only ever exist on a server. Any environment variable starting with VITE_, NEXT_PUBLIC_, REACT_APP_ or EXPO_PUBLIC_ is compiled into the browser bundle.

Details and the fix: exposed API keys in your JavaScript.

2. Row Level Security on every table

If you use Supabase, every table in the public schema needs RLS enabled, with policies that return only the signed-in user's rows. Tables created from AI-generated SQL often have it switched off.

Step by step: how to check Row Level Security.

3. Private storage for user uploads

Avatars on a public bucket are fine. Invoices, IDs, contracts and anything a user uploads privately belong in a private bucket with policies scoped to the owner. Also make sure your bucket list itself is not readable by anonymous visitors.

4. Authorization on the server, not just in the UI

Hiding an "Admin" button is not access control. Every API route, edge function and database policy must check who is asking and whether they may do this to this record. A good test: sign in as user A, copy a request from the network tab, change the record id to user B's, and send it again. It must fail.

5. Nothing private deployed with the site

Make sure your live site does not serve /.env, /.git/, database dumps (.sql, .sqlite) or backup files (.bak, .old). Single-page apps can hide this problem, because a missing file often returns your normal page.

How to check: .env and .git files exposed on your live site.

6. Payments verified on the server

Never trust a price, plan or "paid" flag sent by the browser. Create checkout sessions server-side with prices from your own configuration, and grant access only from a signed webhook from your payment provider, after verifying its signature.

7. Authentication settings reviewed

Turn on email confirmation, set a sensible minimum password length, and keep your auth provider's rate limits on. Check that password reset links expire and cannot be reused. If you allow anonymous or guest sign-ins, make sure they cannot reach paid or private features.

8. Input validated on the server

Validate type, length and format on the server for everything a user sends, even if the form already checks it. Use your database client's parameterized queries rather than building SQL from strings, and escape anything you render back into HTML.

9. Security headers set

At minimum: Strict-Transport-Security, a Content-Security-Policy, X-Content-Type-Options: nosniff, and framing protection (frame-ancestors or X-Frame-Options). Never reflect any origin with credentials in CORS.

What each one does and copy-paste configs: security headers for AI-built apps.

10. Source maps off in production (or deliberately on)

A reachable .map file hands anyone your original, readable source code, including comments and file structure. If you do not need public source maps, disable them in your production build or do not deploy them.

11. Dependencies updated

Run npm audit (or your package manager's equivalent), update anything with a known critical vulnerability, and remove packages the app no longer uses. Generated projects often pull in more than they need.

12. Scan, fix, deploy, scan again

Security is not a one-time setting. Every new feature your AI builder adds can reopen something you closed. Scan the live app before launch, fix what it finds, and scan again after each significant deploy to confirm the fix actually reached production.

The five-minute version

If you only have five minutes before launch:

1. Search your live JavaScript for sk_, sk-, service_role and sb_secret.
2. Run the Supabase Security Advisor and fix every "RLS disabled" warning.
3. Open https://your-app.com/.env and https://your-app.com/.git/HEAD. Neither should show a file.
4. Sign in as one user and try to load another user's record by id.
5. Run a free PreflightX scan and fix every critical finding.

Frequently asked questions

Is an app built with Lovable, Bolt or v0 insecure by default? No. These tools generate code that can be secure. The risk is that the defaults which make a demo work (open tables, keys in the frontend, no server-side checks) also ship to production unless someone checks.

Do I need a penetration test before launch? For most early-stage apps, working through this checklist and an automated scan catches the most common and most damaging issues. Consider a professional test when you handle payments at scale, health data or other regulated information.

What does a PreflightX scan cover? It reads your live app's public surface the way any visitor could: JavaScript bundles for exposed keys, Supabase tables and storage readable with the public key, deployed .env and .git files, database backups, source maps, disclosed paths and security headers. It is read-only and does not sign in, so it is a strong first check, not a full penetration test.