Is It Safe to Expose Your Supabase Anon Key? Yes — Here's Why
Someone opens dev tools, sees your Supabase anon key sitting in the network tab, and the panic sets in. Take a breath: that key is public by design. The real question isn't whether it's visible — it's whether the right key is visible and your policies are doing their job.
What the anon key is for
The anon (now also called publishable) key identifies your Supabase project to the world. Every browser client needs it to talk to your API. Supabase publishes it in their own docs and examples precisely because it's not a secret. Its powers are bounded entirely by your Row Level Security policies.
The key you must NOT expose
The dangerous one is the service_role (or `sb_secret_…`) key. It bypasses RLS entirely — it can read and write every row in every table, no questions asked. It belongs only in server-side code and environment variables. If it ever appears in your front-end bundle or a public repo, rotate it immediately and treat it as a breach.
So what actually protects you?
With the anon key public, your data's safety rests on RLS. If your policies correctly scope rows to their owner, a stranger holding your anon key can do nothing useful. If RLS is off, that same key reads everything. That's why the exposure check and RLS guide matter far more than hiding a key you can't hide anyway.