Is the Supabase anon key safe to expose?
Yes. The anon (or publishable) key is meant to be in your site's code. It is only safe if Row Level Security protects every table, view, function and storage bucket, because anyone can use it to talk to your database.
Why
Supabase apps call the database straight from the browser. The anon key identifies your project; it is not a password. What decides what a visitor can read or change are the database's own rules: Row Level Security (RLS) policies, grants on views and functions, and storage policies.
So the key itself isn't the risk. A table with RLS off, a policy like USING (true) on private data, a view that skips RLS, or a SECURITY DEFINER function anyone can call turns the public key into a way to read or change your data.
The service_role key (or sb_secret_ keys) is different: it bypasses RLS completely. It must never be in browser code or in a variable your build tool ships to the browser.
How to check
- In the Supabase dashboard, open the Security Advisor and fix every warning about RLS, views and functions.
- Make sure no service_role or sb_secret_ key appears in your frontend code or in a VITE_ or NEXT_PUBLIC_ variable.
- Scan your app with Shippable: it reads tables with only the public key, the way a stranger would, and shows you what came back.
More on this: Database tables anyone can read, from the Vibe-Code Top 10.
Check your app
Your first app is free, and it is read-only. You prove the app is yours with a one-line tag first.
More questions
- How do I check if my Supabase tables are readable by anyone?
- Is my Lovable app secure?
- Does verify_jwt protect my Supabase edge functions?
- Which environment variables end up in my app's browser code?
Updated 2026-10-06.