Supabase security scanner: which free tools check what (inside vs outside)

Published October 24, 2026 · By Ember, SniffPup · Tool facts checked October 24, 2026

Short answer: there isn't one Supabase security scanner that sees everything, because your app can leak in three places: inside the database, in the SQL you're about to deploy, and on the live website strangers load. Run Supabase's free Security Advisor for the inside, test your own rules with two accounts, then run an outside scan of your live URL for leaked secret keys and tables that answer to your public anon key. This guide compares the free options by what each one can actually see.

The kinds of Supabase scanners, side by side

1. Inside the database: Supabase Security Advisor

Supabase's advisors are deterministic checks that ship with the platform. Run them in Studio (Advisors → Security Advisor), with the CLI (supabase db advisors), through the Supabase MCP get_advisors tool or the Management API. Fix every error-level finding first, such as a public table with RLS disabled. It's free, it's already in your project and no outside tool can see what it sees. Our Supabase security audit guide walks through each finding.

2. Before you deploy: migration linters and database tests

AI-written migrations are a common way a new table ships without RLS. A migration linter such as rls-lint reads your SQL files offline and flags missing RLS and always-true policies in CI, before anything reaches production. It can't see policies changed in the dashboard. A catalog auditor such as rls-doctor reads the live database's catalog over a Postgres connection instead; its README says it doesn't audit hosted Supabase settings, views or functions.

Linters know common mistakes, not your app's rules. For those, Supabase documents database testing with pgTAP (supabase test db): write a test that signs in as user B and asserts that user A's rows come back empty.

3. On the live site: an outside scan

Everything above looks at the database. Strangers look at your website, and your website ships your Supabase URL and public anon key to every visitor by design. An outside scanner starts from the same place and checks:

• Secret keys in your JavaScript: a service_role or sb_secret_ key in a bundle bypasses every policy you wrote. The anon or sb_publishable_ key is meant to be public.
• Tables that answer to the public key: a read-only request per table to see whether rows come back without signing in.
• Public files: /.env files and their backups, /.git metadata and source maps that reveal your code or keys.

Outside scanners differ in how far they go. SafeToShip's site says its Supabase audit tests your RLS policies from the outside and that its database checks read at most one row. LaunchGuard's Supabase scanner page says it requests every table it can find with the anon key and counts the rows that come back, that it walks your storage buckets and flags the open ones, and that it tests RPC functions it spots in your app's requests (checked October 24, 2026). Read each tool's own page for what it does with your data before you scan.

Signs of a careful scanner: it never asks for your service_role key, it only sends read-only requests, it doesn't download your rows, and it asks you to confirm you own the app.

4. Don't forget the October 30, 2026 change

From October 30, 2026, Supabase applies a new default to all existing projects: new tables in the public schema aren't reachable through the Data API until you add an explicit grant (Supabase changelog). Existing tables keep their grants. This narrows accidental exposure of brand-new tables, but grants and RLS are separate layers: once you grant anon or authenticated access, RLS still decides which rows they see. If a new feature fails with error 42501, add the grant your app needs and an owner-scoped RLS policy, then re-scan.

Which should you run?

1. Security Advisor after every schema change, and fix every error-level finding.
2. A two-user test (or a pgTAP test) for every table that holds personal data.
3. A migration linter in CI if your AI tool writes migrations for you.
4. An outside scan of your live URL after every deploy.

For the RLS steps themselves (SQL to list tables with RLS off, the signed-out curl test and common policy mistakes), see the Supabase RLS checker guide. Built with Lovable? Start with is my Lovable app secure?

Where SniffPup fits

SniffPup is an outside scanner. A free SniffPup scan of your live URL looks for secret keys in your HTML and same-origin JavaScript, including Supabase service_role and sb_secret_ keys (masked in the report), public /.env and /.git files, source maps and security headers. With only the public anon key your site already ships, it reads the table list that key can see and sends one read-only HEAD request per table, up to 8, to learn whether at least one row is readable. It never downloads rows and never writes. On Pro, after you verify you own the domain, a deeper read-only check counts readable rows on up to 30 tables, lists public storage buckets and counts the files anyone can list in them, and checks what your GraphQL API shows signed-out visitors (counts only, never names or contents). It can't see your policies, so use it alongside Security Advisor, not instead of it. See Supabase Security Advisor and SniffPup side by side or the free Supabase exposed data checker.

FAQ

A score of 100 means no issues were found in our checks. It is never proof that your app is secure.

Run a free scan →