SniffPupFree Supabase exposed data checker
Paste your live URL to see what your Supabase-backed site exposes to anyone who visits it. The scan is passive: SniffPup reads your page and the JavaScript it ships, like a normal browser, and never uses a secret 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, plus the full fix free for every critical issue (with no critical, one other fix). Only scan sites you own or are authorized to test. What the scanner does and never does.
What this checks
- Leaked Supabase secret keys. A
service_roleJWT or ansb_secret_key in your HTML, inline scripts or same-origin JavaScript. These bypass Row Level Security, so anyone who copies one can read your whole database. Reported as critical, and masked in the report. - 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. - Public config files such as
/.envand/.git/config, which often hold database URLs and keys. Variable names only, never values. - Pro, after you verify you own the domain: which exposed tables an anonymous visitor can read (row counts only, up to 30 tables) and which storage buckets are public.
What it can't tell you
- The free scan doesn't query your database, so it can't see your Row Level Security policies. Use the Supabase RLS checker guide to check every table yourself.
- It doesn't test writes, signed-in users reading each other's rows, Edge Functions or pages behind a login.
- It scans live web URLs only, not native mobile apps.
- A clean result means no issues were found in our checks. It isn't proof that your data is safe.
Check it yourself in a few minutes
- In your Supabase dashboard, open the Table Editor and make sure every table has Row Level Security enabled.
- Look for policies that use
using (true)on tables with private data. Those let everyone in. - Search your live site's JavaScript in DevTools for
service_roleandsb_secret_. Neither should ever appear. - Scan again after any fix to confirm.
Related: the Supabase service_role key leak checker, the .env exposure checker and the best free security scanners for vibe-coded apps.
Questions
Can the free scan tell me if my Supabase tables are readable by anyone?
No. The free scan never queries your database. It checks what your live site sends to every visitor: secret keys in your HTML and JavaScript, public .env and .git files, and whether your site talks to Supabase. Checking which tables an anonymous visitor can read is part of the Pro deep Supabase check, which only runs after you prove you own the domain.
What does the Pro deep Supabase check do?
It uses your site's public anon key, read-only. It lists the tables your API exposes and checks up to 30 of them, asking for a row count on each without downloading any rows, and lists storage buckets it can see that are marked public. It never inserts, updates or deletes anything and never stores row data.
Is my Supabase anon key in the browser a leak?
No. The anon or sb_publishable_ key is meant to be public. It is only safe if Row Level Security is on for every table your app exposes, with policies that limit what each user can read and write.
Does a clean result mean my data is safe?
No. A clean result means no issues were found in our checks. It doesn't test writes, signed-in users reading each other's rows, or anything behind a login. Check your Row Level Security policies in your Supabase dashboard too.
Does it work for native mobile apps?
No. SniffPup scans live web URLs only, not native iOS or Android apps.