Why Lovable apps leak secrets
Lovable writes frontend code first. The Supabase anon key, Stripe publishable key and analytics IDs belong in the browser. The agent sometimes puts the other keys there too: sk_live_, service_role, Resend, OpenAI. Those bypass Row Level Security and anyone can copy them from the page source.
On r/lovable this is the most repeated launch scare: builders think the green security toggle means they are safe, then a researcher reads every user email from the browser console. This checker only looks at what is already public. It does not query your database or test other people’s apps for you.
What the checker tests
Secrets
- Secret keys in the frontend: Stripe
sk_live_/sk_test_, OpenAI, AWS, GitHub, Resend, SendGrid, private keys and Supabaseservice_role. - Matches are redacted. Rotate the key before you do anything else.
Lovable stack
- Supabase keys: anon / publishable keys are expected. A service_role or
sb_secret_key is an emergency.
Exposed files
- .env and .git: only flagged when the response looks like a real file, not the SPA
index.htmlfallback. - Source maps: a
sourceMappingURLcomment that ships with production JS.
Headers & transport
- HTTPS, security headers (HSTS, nosniff, clickjacking) and mixed content.
Also run the SEO checker and the Open Graph preview before you launch.
How to fix the most common leaks
1. Rotate, then move secrets server-side
Search the frontend for Stripe secret keys, OpenAI keys, AWS keys and the Supabase service_role key. Move every secret into a Supabase Edge Function or server-side env var. Never put sk_live, service_role or API secrets in a React component.
2. Lock Row Level Security for real
Lovable’s built-in scan often checks that a policy exists, not that it blocks anyone. A policy of USING (true) looks locked and reads wide open.
Enable Row Level Security on every public table. Each policy must check auth.uid() against the owner column. Never use USING (true) on tables with user data. Then tell me which tables and policies you changed.
3. Sign Stripe webhooks
Verify every Stripe webhook with stripe.webhooks.constructEvent and the webhook signing secret stored as a Supabase secret. Reject invalid signatures. Store processed event IDs so retries do not grant the plan twice.
Frequently asked questions
Is the Supabase anon key a security leak?
No. The anon or publishable key is designed to ship in the browser. Your real protection is Row Level Security on each table. A service_role key in the frontend is an emergency: rotate it immediately.
Does this checker test Row Level Security?
No. RLS lives in your database, not in public HTML. The checker finds leaked secrets and exposed files, then gives you the Lovable prompt to lock policies down. Never trust a green shield icon without testing with two accounts.
What should I do if a Stripe key is in my JavaScript?
Rotate the key in the Stripe dashboard first so the leaked copy stops working. Then move every secret into a server-side Edge Function. Only the publishable pk_ key belongs in the browser.
Is this security checker free?
Yes. The checker is free, requires no signup and works with any public URL, whether it runs on a lovable.app subdomain or a custom domain.