Guides

Guide · Leaked keys and files

Is the Supabase anon key safe to show? Only if Row Level Security is on

Yes, the anon key (Supabase’s newer name for it is the publishable key) is meant to be in your app’s code, where anyone can see it. What it can do depends on one thing: Row Level Security (RLS). With RLS on and sensible rules, the key is harmless. With RLS off, anyone who copies it can read and change your tables.

The two keys

anon or publishable keyeyJ… with role anon, or sb_publishable_…. It can do only what your RLS rules allow.Public is fine
service_role or secret keyeyJ… with role service_role, or sb_secret_…. It skips RLS entirely.Server only

If a service_role or sb_secret_ key is in your app’s JavaScript, that’s a different, urgent problem: see Your secret keys are in your app’s JavaScript.

Why it matters

In March 2025, missing or weak RLS let strangers read and write the databases of 170+ apps built with Lovable, including home addresses, debts and API keys. It was recorded as CVE-2025-48757. Lovable’s position is that each app’s owner is responsible for their own data, which is true of any Supabase project: the platform gives you the lock, and you decide whether it’s on.

The key isn’t the problem. A table without rules is.

See it yourself

Security Advisor lists no “RLS disabled in public” tablesCheck yourself
No policy’s condition is just trueCheck yourself
Signed-in users only see their own rowsCheck yourself

In Supabase, open Advisors › Security Advisor, then Authentication › Policies. A rule that compares the row’s owner with auth.uid() is the usual way to keep each user to their own rows. Turning RLS on isn’t the same as testing it: a rule can look fine and still let too much through.

Fix it

This is the same prompt our checker gives you:

Paste this into Lovable, Bolt, Cursor or Claude Code

My app uses Supabase. For every table, check that Row Level Security is enabled and that the policies only let users read and change their own rows. List any table without RLS, or with a policy that allows everyone, and write the SQL to fix each one.

Read the SQL before you run it, and run the Security Advisor again afterwards. Tables made by hand, by migrations or by an AI tool can each end up without RLS, so check again whenever you add one.

What this can’t tell you

We don’t test your tables. Reading someone’s database to prove a point, even with a public key, isn’t something we do without permission. So a Supabase reminder means “go and look”, not “you’re exposed”. Only your Security Advisor and your own rules can tell you that. A database test that asks you to prove you own the app first is coming soon.

Related

Sources