Skip to content

What is the anon key, and is it safe to expose?

5 min read

You opened your browser's network tab, saw your Supabase or Firebase key sitting in plain text, and had a small heart attack. Good news and a caveat: the key being visible is fine and by design. Whether that is safe depends entirely on something else.

Two kinds of key, and only one belongs in the browser

  • Public / anon / publishable keys (NEXT_PUBLIC_, anon, pk_...) are meant to ship to the browser. They identify your project and nothing more. Seeing them in the network tab is expected.
  • Secret / service-role keys (service_role, sk_..., anything without a public prefix) grant privileged, rule-bypassing access. These must live only on the server and must never appear in the browser bundle.

The real question is not "is my key visible." It is "which key is visible, and what can it do."

The check

  1. Search your built client bundle (or the network tab) for the strings service_role, sk_live, sk_test, and SECRET. Any hit is a real leak, rotate that key immediately and move it to server-only code.
  2. Confirm the visible key is the public one. If it is, it is doing its job.

Why a public key still isn't your security

A public key with no rules behind it is an open door. On Supabase that means Row Level Security on every table. On Firebase it means Security Rules that deny by default. The key is supposed to be public; the rules are what keep a stranger from reading or writing data they shouldn't. If the rules are missing, the problem is the rules, not the visible key.

Where this fits

Confusing "the key is public" with "the app is exposed" sends founders chasing the wrong fix while the real hole stays open. The free Readiness Report separates the two for your specific project: it flags a genuinely leaked secret as urgent, and it checks whether your public key actually has rules behind it, so you fix the thing that matters.