Guide · Supabase security

Your service key is in your website code.

Updated 26 October 2026 · Postlaunch

Short answer

A Supabase service_role key (or an sb_secret_ key) bypasses all Row-Level Security, so anyone who finds it in your website's JavaScript can read, change or delete your whole database. Legacy keys can no longer be rotated: create new publishable and secret API keys, move every privileged call to a server or Edge Function, update your app, then deactivate the legacy keys and check what was accessed.

1. Confirm it's really exposed

Open your live site, view the loaded JavaScript in the browser's developer tools and search for service_role or sb_secret_. Also search your repository and its history. The anon or sb_publishable_ key is meant to be public; that one isn't the problem.

2. Replace the key

Supabase's docs say the legacy anon, service_role and JWT secrets can no longer be rotated. The fix is to move to the new keys:

  1. In Project Settings → API Keys, create publishable and secret API keys if you don't have them yet.
  2. Use the publishable key in the browser and the secret key only on servers or in Edge Functions you control.
  3. Update every place that used the old keys: the app, Edge Functions, cron jobs, integrations and database webhooks.
  4. Deactivate the legacy keys in the same settings page, and rotate your JWT signing keys if you've migrated to them.

3. Stop it happening again

Anything that needs elevated rights, like admin actions, webhooks or AI calls, should run in an Edge Function or server, with the secret stored as a function secret. Tell your AI builder explicitly never to use the service or secret key in frontend code.

4. Check what happened

Look at your Supabase logs for unusual reads, writes or deletes while the key was public, and check for new admin users or changed data. If personal data may have been accessed, get legal advice about notification duties where you and your users are.

Want it handled now?

A leaked key is urgent. Tell us on the call or by email and we'll prioritise it: key replaced, privileged calls moved server-side, and RLS locked down and tested. A single fix is $249, and Data lockdown is $290. If we can't fix it, you don't pay.

Get help now →Email us

Questions

Why is an exposed service_role key so serious?

The service_role key, and the newer sb_secret_ keys, bypass Row-Level Security completely. Anyone who copies it from your website can read, change or delete everything in your database.

Can I just rotate the legacy service_role key?

Supabase's docs say the legacy anon, service_role and JWT secrets can no longer be rotated. Move to the new publishable and secret API keys, update your backend, then deactivate the legacy keys.

Is the anon key also a secret?

No. The anon or publishable key is meant to be public; Row-Level Security is what protects your data. Only service_role and sb_secret_ keys must never reach the browser.

Can you handle it for me?

Yes. We treat it as urgent: replace the key, move privileged calls server-side and lock down RLS. A single fix is $249, or Data lockdown is $290; tell us it's a leaked key and we prioritise it.

Sources: Supabase: rotating keys · Supabase: migrating to new API keys