Is the Supabase Anon Key Safe to Expose?
Updated 2026-10-17
Short answer: yes, the anon (or sb_publishable_) key is meant to ship to browsers. The longer answer is that it is only safe if your database policies are.
What the anon key does
It identifies your project and lets requests run as the anon role (or authenticated once a user signs in). Postgres grants and RLS policies decide everything those roles can do.
Keys that must stay secret
- service_role JWT (role claim
service_role) sb_secret_keys- Database connection strings and passwords
- JWT secret
Checklist
- Only anon/publishable key in the client
- RLS on all exposed tables
- Exposed schemas limited to what the app needs
- Rate limits / CAPTCHA on auth where abuse is likely
Copy-paste fix prompt
Confirm my client only uses the Supabase anon/publishable key, then list every table and view reachable through the API with its RLS status and policies so I can review them.FAQ
Should I rotate the anon key regularly?
It is not a secret, so routine rotation has little value. Rotate if you are rotating the JWT secret after a service_role leak.
Can someone spam my database with the anon key?
If policies allow anonymous inserts, yes. Require authentication for writes and consider rate limits.
Check your deployed app in ~25 seconds
Free passive scan: leaked keys, Supabase exposure, public config files and headers.
Run a free scan