Supabase
The Supabase anon key: what it is, where to find it and when it is safe.
The Supabase anon key is the legacy public key that lets browser code connect to your project. It is meant to be visible. Newer projects use an sb_publishable_ key for the same low-privilege job. Both are safe only when row-level security limits what the public API can read and write.
The key is not the problem. The missing rule is.
People find the anon key in their page source, panic, and try to hide it. That is the wrong fix, because the key is public by design and cannot be hidden from a browser that needs to use it. The real question is what the key can reach. With row-level security on, it can only do what your policies allow. With RLS off, a key that is meant to be shared becomes a master key to data that is not.
What the Supabase anon key is
The legacy anon key identifies your Supabase project and lets frontend code call its API. Without a signed-in session it uses the anon database role. With a valid user session it acts as the authenticated role. Row-level security policies decide what either role may do.
Supabase is replacing legacy anon keys with publishable keys that begin sb_publishable_. The name and format changed, but the browser-side job is the same. A publishable key may appear in your JavaScript bundle. A secret or service-role key may not.
Where to find the anon or publishable key
Open your Supabase project and go to Project Settings, then API Keys. New projects show a publishable key beginning sb_publishable_. Older projects may also show the legacy anon JWT. Copy the public key into the browser-side environment variable your framework expects.
The dashboard also shows secret or service-role credentials. Do not copy those into variables exposed to the client, including VITE_, NEXT_PUBLIC_ or REACT_APP_ variables. Those prefixes put their values into the deployed JavaScript bundle.
Why the public key is only safe with RLS
A public key becomes dangerous when an exposed table has no working row-level security. A stranger can copy the key from the browser and call Supabase directly, without using your interface. If a table is open, that direct request can read or change rows your screen never showed.
Hiding the key does not fix that. A browser needs the key to make the request, so a visitor can always recover it. The fix is a policy that restricts each user to the rows and operations the product intended.
How to test whether the key is safe
Enable RLS on every exposed table and review its policies. Then query the API without a login using the exact public key that shipped in the deployed bundle. Each table should return only intentionally public records or no rows.
Repeat the test with two ordinary accounts. Account A should not be able to read, update or delete Account B's private records even when it changes the request outside the interface. That cross-account check proves the database rule holds when the frontend is bypassed.
Common questions.
- Someone found my Supabase anon key. Am I compromised?
- Not by the key being visible, because it is public by design. Whether you are exposed depends on your row-level security. If RLS is on and your policies are correct, the visible key can only do what you allowed. If RLS is off, the key can reach everything, and that needs fixing now, but by adding policies, not by hiding the key.
- Where do I find the Supabase anon key?
- Open the project in Supabase, go to Project Settings and then API Keys. Newer projects use an sb_publishable_ key instead of the legacy anon JWT. Both are the public browser-side credential.
- What replaced the Supabase anon key?
- Supabase replaced legacy anon keys with publishable keys beginning sb_publishable_. They serve the same low-privilege browser role and still depend on row-level security to limit access.
- What is the difference between the anon key and the service role key?
- The anon key is public and respects row-level security. The service role key is secret, bypasses RLS entirely, and must stay on the server. Confusing the two, or shipping the service role key to the browser, is a critical mistake.
- Can you check whether my anon key exposes anything?
- Yes. Our Supabase security audit queries every table with the anon key exactly as an attacker would and tells you what, if anything, comes back that should not.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.