← All guides

How to check if your Lovable app leaks your Supabase key

Updated 22 October 2026 · 6 min read

Short answer: Seeing your Supabase URL and anon/publishable key in the browser is normal. The danger is a service_role or sb_secret_ key in your frontend, or tables with Row Level Security turned off. Search your site's public JavaScript for those keys, then check RLS on every table.

Which Supabase keys are safe to show?

Supabase's own docs put it simply: the publishable key (and the older anon key) is "safe to expose" as long as Row Level Security is on. The secret key (and the older service_role key) "bypass Row Level Security" and must never leave your server. (Supabase API keys docs)

• Safe in the browser: sb_publishable_… or a long eyJ… key whose role is anon
• Never in the browser: sb_secret_… or an eyJ… key whose role is service_role

Why does this matter so much?

In 2025 a researcher scanned 1,645 apps from Lovable's showcase and found 170 of them (10.3%) had database endpoints anyone could read, exposing user tables, transactions, subscriptions and even API keys. It became CVE-2025-48757, rated 9.3 (critical). (full write-up) Lovable now runs a security scan when you publish (Lovable security), but a second check never hurts.

How do I check my app in 5 minutes?

1. Run a free Vibe Check. Paste your URL. It reads your public JavaScript and flags secret keys, with the values redacted.
2. Or check by hand: open your app in Chrome, press F12, go to Sources, press Ctrl+Shift+F (Cmd+Opt+F on Mac) and search for service_role, sb_secret and sk-.
3. Open the Supabase dashboard → Advisors → Security Advisor and fix every error it lists.
4. Test with two accounts: sign in as user A and make sure you can't see user B's data.

What if I find a secret key?

Paste this into your AI builder:

My frontend contains my Supabase service_role (or sb_secret_) key, which bypasses all security. Remove it from all client code. Use only the publishable/anon key in the browser, and move admin actions into an Edge Function that reads the secret from environment secrets.

Then rotate the key in Supabase (Settings → API Keys). Removing it from the code isn't enough: anyone who already copied it still has it.

What if Row Level Security is off?

Paste this:

Go through every table in my Supabase database. Turn on Row Level Security for each one. For tables with user data, add policies so a signed-in user can only select, insert, update and delete rows where user_id = auth.uid(). Remove any policy that uses `true` for everyone. Don't change the app's features. When you're done, list every table with its policies in a simple table.

Read more in our Supabase RLS guide for non-coders.

FAQ

Is the Supabase anon key a secret?

No. It's designed to be public, but it's only safe if Row Level Security is enabled with correct policies on every table.

Does Lovable fix this automatically?

Lovable runs a basic security scan on publish and offers a deeper scan, but you should still verify RLS policies match your app's logic.