What is Supabase anon key?
Supabase's public API key designed for client-side use. Carries no privilege beyond what RLS policies grant to the `anon` role. Safe to ship in your client bundle — by design.
Full explanation
Supabase issues an anon key per project, intended for use in browser code. The key authenticates the request as 'anonymous' role; what the request can read or write is determined by your RLS policies + role grants. The anon key is meant to be public — it ships in the client bundle where every visitor can read it, and that is the design. The risk is not the anon key itself; it is over-broad RLS policies or anon-role grants that make the anon key more powerful than intended.
Example
createClient(SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY) in client code is correct. The anon key authenticates the request; RLS policies enforce what data the anonymous user can read. If RLS is missing or the anon role has been granted excess privileges, the anon key becomes an attack surface — but the fix is the policies, not the key.
Related
FAQ
Can I treat the anon key as a secret to be rotated?
No — the anon key is public by design. Rotating it requires updating every deployed client, breaks all in-flight sessions, and does not improve security if RLS is correct. If your anon key feels like it needs rotation, the problem is over-permissive RLS, not the key itself.
What's the difference between anon and authenticated roles?
anon = unauthenticated requests (visitor not logged in). authenticated = requests with a valid JWT in the Authorization header (logged-in user). RLS policies typically grant authenticated users access to their own rows; anon should rarely be granted SELECT on user data.