My Supabase anon key is in my client-side code. Is that bad?
No — the anon key is designed to be public. It's in every Supabase tutorial and every shipped app. The key that MUST never be public is the service-role key (`SUPABASE_SERVICE_ROLE_KEY`). Anon-key safety depends entirely on whether your RLS policies are correct. Bad RLS + public anon key = full data leak.
Supabase gives you two keys:
**Anon key** — meant to be public. It's the key your web / mobile app uses to talk to Supabase as a regular user. Exposing it in client JavaScript is expected. The anon key respects your RLS policies, so it's only as safe as your policies are.
**Service-role key** — must stay server-side. It bypasses RLS and can do anything. If this key is public, every row in your database is readable and writable by anyone. Never put it in client code, never commit it to a public repo, never share it in a screenshot.
The risk with the anon key is not the key itself — it's that most Supabase apps ship with broken or missing RLS. If your tables don't have RLS enabled, or if the policies say `using (true)`, the anon key lets anyone read everything. That's not a key-leak bug; that's an RLS bug.
Check which key is where: - In Supabase dashboard: Settings → API shows both keys - The service-role key is labeled with a red warning - Search your codebase for the service-role key value — it should only appear in server-side files (`.ts` files under `app/api/`, serverless functions, etc.), never in components that render to the browser.
Securie's scan (launching this year) will flag every place a service-role key appears, plus check whether your RLS is tight enough for the anon key to be safe. Join the list to have it run on your app in week 1.