Is my Lovable app secure? A 15-minute pre-launch check
Lovable, Bolt and similar AI builders get you from idea to live URL in an afternoon. The code they generate is usually functional. Whether it’s safe to launch is a separate question, and the answer depends on a handful of settings the AI may never have touched. Here is the exact checklist we run, in order of how much damage each problem causes.
1. Make sure no secret keys are in your frontend
Everything in a Lovable app’s src/ folder is compiled into JavaScript that every visitor downloads. Any key you can see in your code, anyone can see in their browser’s DevTools. Bots crawl new sites looking for these patterns within hours.
| Safe in the browser | Never in the browser |
|---|---|
Supabase URL + anon / sb_publishable_ key | Supabase service_role / sb_secret_ key |
Stripe pk_live_ publishable key | Stripe sk_live_ / rk_live_ keys |
| Firebase web config (apiKey, projectId) | Firebase service account JSON |
| Google Maps key restricted to your domain | OpenAI sk-proj-, Anthropic sk-ant-, AWS AKIA…, SendGrid, Resend keys |
How to check: open your live site, press F12, go to the Sources tab and search (Ctrl/Cmd+Shift+F) for sk_live, sk-proj, sk-ant, service_role and AKIA. Or let ShipGrader read every bundle for you.
If you find one: revoke it at the provider first (deleting it from code doesn’t help, since it’s already public), then move that call into a Supabase Edge Function and store the key as a function secret.
2. Turn on Row Level Security for every Supabase table
Most Lovable apps use Supabase. Your anon key is public by design. The only thing stopping a stranger from running select * from profiles with it is Row Level Security (RLS). A table without RLS is readable, and often writable, by anyone on the internet.
- Supabase Dashboard → Table Editor: every table should show RLS enabled.
- Open Advisors → Security Advisor and fix every “RLS disabled in public” warning.
- Read each policy.
using (true)on select is only OK for genuinely public data; never use it for insert, update or delete.
Our Supabase RLS checklist has copy-paste policies.
3. Check you’re not serving .env, .git or source maps
If you export your project and deploy it yourself, it’s easy to accidentally upload the whole folder. Visit yoursite.com/.env and yoursite.com/.git/config. If either downloads a file, take it down and rotate every key in it. Also check whether .js.map files are public. They expose your original source code.
4. Add basic security headers
Headers are instructions your host sends with every page. The four that matter most:
Add a Content-Security-Policy next, starting in report-only mode. On Netlify use a _headers file, on Vercel the headers key in vercel.json, and on Cloudflare a Transform Rule.
5. Cap your AI and cloud spend
The scariest launch stories aren’t data leaks. They’re bills. If your app calls OpenAI or Anthropic, set a hard monthly limit in the provider’s billing settings today, and add per-user rate limits in your Edge Function. Do the same with budget alerts on Google Cloud, AWS or Firebase (Blaze plan).
6. Publish Privacy, Terms and Refund pages
As soon as you collect an email address you need a privacy policy (GDPR, CCPA/CPRA, CalOPPA). Stripe, Google sign-in and app stores also require one. If you charge money, you need terms and a clear refund policy, and they must match what your pricing page promises. Our guide to writing a privacy policy for an AI app covers what to include.
The 60-second version
- No secret keys in the browser
- RLS on for every table, Security Advisor clean
- /.env and /.git/config return 404
- HSTS, X-Frame-Options, nosniff, Referrer-Policy set
- Hard spend caps on AI and cloud accounts
- Privacy, Terms, Refund pages linked in the footer