Is your key safe in your app?

Paste your URL into the free outside-in scan. It checks if your public key can read tables it shouldn't, and if a secret key leaked into your frontend. No signup.

Is the Supabase anon key safe to expose?

Short answer: yes, by design. But only if Row Level Security (RLS) is on for every table. The key is safe. An open table is not.

Two kinds of keys

Publishable key (sb_publishable_..., or the legacy anon key, a long JWT that starts with eyJ). Low access. Fine in browsers, mobile apps and source code.

Secret key (sb_secret_..., or the legacy service_role key). Full access. It skips RLS. Use it only on servers and in Edge Functions. Never in a browser, an app bundle or git.

Supabase's docs put it this way: the publishable key is taped to the front door and only opens the lobby. The secret key is the master key. Supabase plans to retire the legacy anon and service_role keys by the end of 2026.

Why showing the anon key is OK

Anyone can find the publishable or anon key in your web page, app bundle or browser Network tab. Supabase treats it as public. Requests with it run as the Postgres role anon, or authenticated once a user signs in. Your RLS policies decide what those roles can see.

When it is NOT OK

1. RLS is off on a table. Then the public key can reach that table. Supabase says to turn on RLS for every table before you deploy.

2. A policy is too open. For example, a policy that lets anon read every row. Check your anon and authenticated policies often.

3. You shipped the secret or service_role key. It skips every policy. This often happens when the key is put in a NEXT_PUBLIC_ or VITE_ variable, or pasted into client code.

Quick self-check

Open the Supabase Security Advisor and review every finding. Search your frontend bundle for sb_secret_ and service_role. Make sure RLS is on for every table in the public schema. See our Supabase RLS check for the SQL.

If you leaked the secret key

Supabase's steps: fix the cause of the leak first. Then make a new secret key in Settings > API Keys. Swap it in everywhere. Check that every part of your app uses the new key. Then delete the old key. For legacy keys, turn them off in the same place instead.

Check it in 60 seconds.

Start with the free outside-in scan. Want your real RLS policies reviewed? Deep Scan, €9 one-off.

Based on the official Supabase API keys docs. VibeGuard is independent and not linked to Supabase.