Lovable security scan: how to check your Lovable app before (and after) you launch

Lovable makes it easy to go from prompt to live app in an afternoon. The trade-off is that you didn't write the code, so you don't know what's in it. This guide covers what a security scan of a Lovable app should check, how to check each item yourself, and how to keep checking as the AI keeps changing your app.

Start with Lovable's built-in security review

Lovable includes its own security scanning, which inspects your project from the inside (code and Supabase configuration). Run it and fix what it reports. It's free and it knows your project structure. An outside-in scan like ShipCheck is complementary: it looks at the deployed site the way an attacker or Google sees it, and it re-checks on a schedule.

1. Secrets in your JavaScript bundle

Lovable apps are typically Vite + React single-page apps. In Vite, any environment variable prefixed with VITE_ is compiled into the JavaScript that every visitor downloads. If a Stripe secret key, OpenAI key or Supabase service key ever ends up in a VITE_ variable, or is pasted directly into a component, it's public.

How to check: open your live site, open DevTools → Sources (or view the files under /assets/), and search for sk_live, sk-, service_role, sb_secret_ and AKIA. Anything you find must be rotated (revoked and replaced), not just deleted, because it may already have been copied.

The fix: secret keys belong in server-side code only, such as a Supabase Edge Function that reads them from Supabase secrets. The browser calls your function, never the third-party API directly.

2. Supabase Row Level Security

Most Lovable apps use Supabase. The Supabase URL and the anon/publishable key are always visible in your frontend; that's by design. What protects your data is Row Level Security (RLS). If a table in the exposed schema has RLS switched off, or has a policy like using (true), anyone can read it with the public key. Read is the Supabase anon key safe? for the full explanation and how to check RLS.

A common trap: a security tool confirms RLS is enabled, but a permissive policy still lets everyone read every row. The only reliable test is to try reading each table anonymously, which ShipCheck does for verified owners (counting rows with HEAD requests, never downloading data).

3. Exposed files and source maps

• /.env: if a .env file gets copied into public/, your host will serve it to anyone.
• /.git/: only an issue if the repository root is deployed instead of the build output.
• Source maps (.js.map): they reveal your original source code and comments. Turn them off for production builds (build.sourcemap: false in Vite) unless you upload them privately to an error tracker.

Watch out for false alarms when checking by hand: single-page apps often return the homepage HTML with status 200 for any path, so /.env "loading" isn't proof of a leak. Look at the content.

4. Security headers

Headers such as Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and X-Content-Type-Options are set by your host, not your React code. Check them with curl -I https://your-app.com. Where you can add them depends on where the app is hosted.

5. Don't forget findability

Not security, but just as painful: client-rendered apps can look empty to crawlers that don't run JavaScript. Run curl https://your-app.com and check that your headline text, <title> and meta description are in the raw HTML. Also make sure a noindex tag or a canonical URL pointing at your *.lovable.app preview domain didn't survive into production.

6. Re-check after every big change

Every prompt can touch dozens of files. A key that was server-side last week can move into a component this week. That's why ShipCheck re-scans weekly (or daily) and emails you a diff: what's new, what's fixed, what's still open, with a copy-paste prompt to paste back into Lovable for each issue.

Copy-paste prompt: ask Lovable to audit itself

Audit this project for security issues before launch:
1. List every place an API key or secret is used. Any secret used in frontend code
   or in a VITE_ variable must move to a Supabase Edge Function using Supabase secrets.
2. List every Supabase table, whether RLS is enabled, and what each policy allows.
   Flag any table without RLS and any policy using "true" for anonymous users.
3. Make sure no .env file is in the public folder and production source maps are off.
Show me the changes before applying them.