Is the Supabase Anon Key Safe to Expose?

The Short Answer

Yes. The Supabase anon key is a public key. It is designed to be embedded in your frontend JavaScript, and Supabase intends for anyone to be able to see it. That is not a leak, it is how the client talks to your project. The catch is in why it is safe: the anon key is safe to expose only because row-level security is meant to sit between that key and your data, and decide what the holder is actually allowed to do.

So the honest version of the answer is conditional. The anon key is safe to expose if, and only if, your RLS is correct on every table it can reach. The moment a table has RLS disabled or a policy that allows too much, the public anon key stops being harmless and becomes a direct line into that table. The question is not really "is the key safe", it is "is my RLS correct".

What the Anon Key Actually Is

When you create a Supabase project you get a public anon key and a URL. Your frontend uses them to call the auto-generated REST API (PostgREST) and the Realtime and Storage services. The anon key identifies requests as coming from the anonymous or, after login, the authenticated role, and every one of those requests is still filtered by the row-level security policies on the tables involved.

In other words, the anon key does not grant access by itself. It is a ticket that says "this request is from the anon or authenticated role", and your policies decide what that role can see and change. This is why Supabase can safely tell you to put the key in your frontend: the security boundary was never the key, it was always RLS.

The service_role Key: The One That Is Actually Dangerous

Alongside the anon key, Supabase gives you a service_role key, and this one is completely different. The service_role key bypasses row-level security entirely. It is a superuser key over your data, intended for trusted server environments such as backend APIs, Edge Functions and scheduled jobs, where you have already done your own authorisation.

Because it ignores RLS, a leaked service_role key is a full compromise of your database, no clever exploitation required. The common ways it leaks are depressingly simple: a developer swaps the anon key for the service_role key to "unblock" themselves and forgets to revert, it gets committed to a public repository, or it is placed in a client-side environment variable that ends up in the browser bundle. Check your frontend, your env files and your git history for it, and if it has ever been exposed, rotate it.

What the Real Supabase Leaks Have in Common

The Supabase data exposures reported through 2026 are not stories of attackers defeating strong security. They are stories of the public anon key doing exactly what it is supposed to, against data that was never protected. The patterns repeat:

• RLS left off entirely. A table created without enabling RLS is readable and writable by anyone with the anon key. Reported incidents this year, including one where a newly launched app exposed a large volume of records, trace back to this single default.
• Partial or permissive policies. RLS can be enabled and still leak if a policy is too broad, for example an INSERT policy with no role specified that lets anon write, or a SELECT policy using true. A class of RLS-bypass issues affecting some Supabase-based apps was serious enough to receive a CVE this year.
• A leaked service_role key. Once that key is public, RLS is irrelevant and every table is exposed.
• Missing ownership checks. Apps that trust a client-supplied id let one user request another user's data by swapping the id, an access-control flaw RLS would have caught if the policy checked auth.uid().

How to Tell If Your Anon Key Is Actually Safe

There is a simple mental test: imagine your anon key is printed on a billboard, because effectively it is. Now ask what an attacker holding it could do. If the answer is "nothing beyond what any anonymous visitor should do", your RLS is doing its job. If the answer involves reading other users' data or writing records they should not, you have a problem that hiding the key would never have fixed.

Concretely: enable RLS on every exposed table, scope each policy to the authenticated user's own data, keep the service_role key server-side, and then test it. Sign in as one user, grab the anon key from your own browser, and try to read and write another user's rows directly against the REST and RPC endpoints. If anything you should not be able to touch comes back, that is what an attacker sees too.

Beyond the Keys: Where RLS Still Leaks

Even teams that handle the keys correctly get caught by the objects that sit in front of their tables. SECURITY DEFINER functions run with the owner's rights and ignore RLS, and Supabase exposes them as callable RPCs, so an unguarded one is a bypass regardless of how careful your policies are. Views can similarly run with the owner's privileges unless created with security_invoker. And RLS protects rows, not columns, so a user who can update their own row can change any column in it without column-level grants and a WITH CHECK clause.

These are exactly the issues we find in real audits, including the case study where row-level security was enabled on all 113 tables and still had two High-risk findings. The anon key was never the weak point. The weak points were the policies, functions, views and grants behind it.

Confidence, Not Guesswork

If you are shipping real user data on Supabase, you should be able to say more than "the anon key is supposed to be safe". You should be able to demonstrate it: RLS on every table, scoped policies with WITH CHECK, the service_role key provably server-side, functions and views that respect the caller, and cross-tenant tests that prove isolation. That is the difference between hoping your key is safe and knowing it.

A focused Supabase security review gets you there quickly. We read every policy, function, view and grant, test what the public key and an authenticated user can actually reach, and hand you a prioritised report with the exact fixes, so "is the anon key safe" becomes a question you can answer with evidence.