Supabase Service Role Key Exposed: Rotate It, Then Check What It Touched

Row level security is the lock on every table, and this key is the one Supabase gives your server so it can work without the lock. Once it is outside the server, the policies you wrote stop protecting anything from whoever holds it. A database exposed this way gives no warning: the requests look like your own backend.

The leak usually happens by accident. A key copied into a frontend environment variable gets compiled into the JavaScript every visitor downloads. Code generated quickly, by people or by coding assistants, reaches for the key that makes an error go away, and the secret key always works. A debugging session logs a request header. Each of these keeps the app running perfectly, which is why the key can sit exposed for weeks.

Supabase has narrowed the damage for its newer keys. A secret key returns HTTP 401 when it comes from a browser, and GitHub reports one pushed to a public repository to Supabase for revocation. Neither protection stops someone who copied the key from a bundle or a log and uses it from a script, and the legacy service role key has neither.

Find how it leaked, then rotate. Remove the key from the client code, repository, or log it reached, and fix the build setting that put it there, or the replacement will leak the same way. If the logs show someone actively using the key, retire it first, accept the brief breakage, and fix the leak right after.

Create a new secret key for each backend component. In Settings, under API Keys, create a secret key per server, function, or job that needs one. A separate key per component means the next leak costs one rotation instead of all of them.

Store the new key where only the server can read it. Put it in a managed secrets store, such as AWS Systems Manager Parameter Store or Secrets Manager, encrypted under a key your company controls. The server fetches it at startup through a role scoped to that one secret, so the key never sits in the build, the repository, or an environment file a frontend can read. Write it there straight from the dashboard or a pipeline, so nobody pastes it into chat or a ticket on the way. Then turn on audit logging for reads of that secret (CloudTrail on AWS) and alert when anything other than the server's own role reads it.

Replace it everywhere, then retire the old key. Update every server, Edge Function, database webhook, and scheduled job that used it. Delete a compromised secret key; deactivate the legacy keys if the leak was the service role key, and move browser and mobile clients to a publishable key first, since deactivation retires the anon key too. Never turn a retired key back on to rescue a client you missed; give that client a new key instead.

For a legacy service role leak, revoke the JWT secret. The legacy keys are tokens signed by your project's JWT secret, so anything that still trusts that secret can still accept the leaked key. Supabase's path is to migrate to JWT signing keys and revoke the legacy secret. Revoking signs out users whose sessions were issued under the legacy secret; during an active incident that is the right trade. Check first whether any of your code verifies tokens against the legacy secret directly, since that code breaks at revocation.

Check what the key touched, and export the logs now. Log retention depends on your Supabase plan, so pull the API gateway logs for the window between exposure and retirement before they age out. Look for requests from addresses that aren't yours and calls to tables, storage, or user administration your backend doesn't make, and compare your data against a recent backup for changes nobody on your team made. The logs may not show which key made a request, and database reads appear only if statement logging was on, so an empty result does not prove the key went unused. If the exposure is older than your retention, record that use cannot be ruled out. Then confirm the retired key is rejected, and keep the timeline and the review as the evidence that the finding is closed.