SniffPupFree Supabase service_role key leak checker
Paste your live URL to check whether your published site sends a Supabase secret key to every visitor's browser. It's passive: SniffPup reads your page and the JavaScript it ships, like a normal browser, and never uses a key it finds.
This runs SniffPup's normal free scan, so you get the whole report, not just this one check. Supabase results are listed as “Exposed Supabase service_role key”, “Exposed Supabase secret key” or “Supabase backend detected”. The free report lists every issue it finds with its severity and shows the full explanation and fix for the most serious one. Only scan sites you own or are authorized to test. What the scanner does and never does.
What this checks
- Supabase service_role keys (JWTs with the
service_rolerole) in your HTML, inline scripts and same-origin JavaScript bundles. Reported as critical. - Supabase secret keys (
sb_secret_…). Reported as critical. - Whether your site talks to Supabase from the browser, and whether the public anon or
sb_publishable_key is present. That's normal and shown as information, not as a problem. - As part of the same free scan: other secret keys (OpenAI, Stripe, AWS and more), public
.envand.gitfiles, and security headers.
Any key found is masked in the report.
What it can't tell you
- It does not check Row Level Security or query your database. A site with no leaked keys can still have tables anyone can read. See the Supabase RLS checker guide to check that yourself.
- It reads up to 20 same-origin JavaScript files from the page you enter. Scripts on other domains, pages behind a login and server code aren't checked.
- It can't see Edge Functions or anything on Supabase's side. A clean result isn't a guarantee that your app is secure.
Check it yourself
Open your published site, open DevTools, then Sources, and search all files (Ctrl+Shift+F, or Cmd+Option+F on Mac) for service_role and sb_secret_. A service_role key is a JWT, so it may not contain the word itself: paste any long eyJ… token you find into a JWT decoder you trust, offline if possible, and look at its role claim. anon is fine; service_role is a leak.
How to fix a leaked key
- Rotate the key in your Supabase project's API settings.
- Move the code that needed it into a server-side function, so only the anon or publishable key runs in the browser.
- Make sure Row Level Security is on for every exposed table.
- Scan again to confirm.
More: your Supabase “secret” key might be in your JavaScript.
Questions
Is it a problem that my Supabase anon key is in my JavaScript?
No, the anon or sb_publishable_ key is meant to be public. It is only safe to expose if Row Level Security is on for every table your app exposes. The service_role and sb_secret_ keys are different: they bypass Row Level Security and must never reach the browser.
Does this checker test my Row Level Security?
No. The free scan never queries your database. It tells you when your site uses Supabase and whether a secret key is exposed. SniffPup's optional Pro deep check can test which tables are readable with your public anon key, read-only, and only after you verify you own the domain.
Does SniffPup use the keys it finds?
No. It pattern-matches what your site already sends to every visitor, masks any secret in the report and never uses a secret key it finds.
My service_role key was in my frontend. What now?
Rotate it in your Supabase project's API settings right away, move any code that needed it to a server-side function, and scan again. Assume the old key was copied.