Supabase service role key exposed: what to do now

By Shinobi Tech, the team behind AppLeakWatch. Updated .

Treat it as an emergency. The service role key bypasses row-level security, so anyone holding it may be able to read, change or delete your data. Replace the key first, then find out how it got out.

Why this happens

If it's in your browser code, it was sent to every visitor. Removing it from the code isn't enough, because copies may already exist. The old key has to stop working.

How to check

  1. Search your built files for it:
    grep -r "service_role" dist/ build/ .next/static/
  2. Open your site, view its JavaScript files in browser dev tools, and search for eyJ. Decode any long token and look for the role.
  3. Check your git history too. A key removed from today's code can still sit in an old commit.

How to fix it

  1. Create a new key in your Supabase project's API settings and revoke the old one.
  2. Update every server that uses it.
  3. Move all use of the key into server functions.
  4. Review your data and logs for changes you can't explain.

Prompt for your AI tool

Find every use of the Supabase service role key in this project. Move all of them into server-side functions so the key never reaches the browser, read it from a server environment variable, and show me each file you changed.

Review what your AI tool changes, and test the live site afterward.

Catch this before a stranger does

AppLeakWatch keeps checking your live app and emails you when something new appears.

Start your 7-day trial

Common questions

Can I just delete it from my code?

No. Replace it too. Assume anything that reached a browser or a public repository has been copied.

How do I know if someone used it?

Check your Supabase logs and look for unusual reads or changes. Logs may not cover everything, so treat a clean log as reassuring rather than proof.

Related guides