Is it safe to expose the Supabase anon key?

By Shinobi Tech, the team behind AppLeakWatch. Updated .

Yes, the anon or publishable key is designed to appear in browser code. It's only safe when row-level security protects your tables, because anyone can copy that key and use it to call your database.

Why this happens

The key is like a building's front door address, not a master key. Row-level security decides what a person can do once they arrive. With it off, the public key can be enough to read a whole table.

How to check

  1. Test a table with your public key. On your own project, replace the capitals:
    curl "https://PROJECT.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY"
  2. If you get real rows back with no login, that table is open.
  3. An empty list [] can mean there are no rows or that the rules blocked you, so check with a table you know has data.

How to fix it

  1. Turn on row-level security for every table in the public schema.
  2. Add a policy for each thing users should be able to do.
  3. Leave the anon key where it is. Rotating it won't help if the tables are open.

Prompt for your AI tool

List every Supabase table in this app. Turn on row-level security for each one and write policies so only the right signed-in user can read or change a row. Tell me which tables are meant to be public and why.

Review what your AI tool changes, and test the live site afterward.

Catch this before a stranger does

AppLeakWatch keeps checking your live app and emails you when something new appears.

Start your 7-day trial

Common questions

Should I hide the anon key in an environment variable?

You can, but it still ends up in the browser. It isn't a secret, so hiding it doesn't protect anything.

What about the service role key?

That one bypasses row-level security and must stay on your server.

Related guides