Supabase security tools compared: what each one catches and misses

By Ohad Krispin, founder of VibeRaven · LinkedIn

No single tool covers a Supabase app, because each one reads only one layer of it. Start with the database you have deployed: Supabase's Security Advisor is built in and checks the policies, grants and functions that are actually live, including changes made in the dashboard. Then add a check of your migrations and code before each deploy, a scan of the deployed app from outside, and a secret scanner on every commit. The tools below are grouped by the layer they read, not ranked, and each is described from its own docs, read on 2026-10-22.

Diagram of the four layers of a Supabase app, code and migrations, the running database, the deployed app and secrets, with what a check at each layer catches and what it cannot see.

To check one migration file before you push it, paste it into the free Supabase RLS checker.

Checklist

Which tools cover which layer

01Code and migrations, before deploy: these read your repo, so they catch a bad migration before it reaches the database, and they cannot see tables or policies changed in the dashboard. rls-lint reads migration SQL offline (npx rls-lint ./supabase/migrations) and exits 1 on critical findings. supabase-security replays your migrations with no credentials (npx supabase-security migrations). The Supabase CLI runs the Advisor checks on your local database: apply your migrations with supabase db reset, then run supabase db advisors --local.
02Code and migrations, VibeRaven: an open source CLI for Vercel + Supabase apps (npx -y viberaven@1.6.12 check). On a fixture repo on 2026-10-22 it flagged a public table without RLS, an update policy using (true), a security definer function the anon key can call, a service role key in client code, a Stripe webhook with no signature check and an env var missing from .env.example. It is advice, not a gate, and a repository check, not a live database test: it does not connect to Supabase, Vercel or Stripe, so it cannot see live policies or how the app behaves at runtime, and a clean result does not prove the app is secure. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore.
03The running database: these read what is deployed, dashboard changes included, and cannot see a migration you have not applied. The Security Advisor runs in the dashboard, with supabase db advisors --linked, through the MCP get_advisors tool and through the Management API. pgTAP tests, run with supabase test db, set a user's role and JWT and assert which rows come back. Supashield checks each role's access against the results you expect in a policy.yaml file, inside transactions it rolls back. Supabomb lists what the anon key can reach; its README says to use it only for authorized testing.
04The deployed app, from outside: these start from your public URL, as a stranger would, and do not read your source or migrations. ZAP's baseline scan crawls the site and scans passively; its full scan runs real attacks, which ZAP says to point only at an app you have permission to test. Vibe App Scanner, RowShield and LeakScope are hosted scanners for Supabase apps that start from your app's URL and report the data a visitor can reach.
05Secrets, on every commit: these scan files and git history for keys and say nothing about RLS. Gitleaks runs as a CLI, a pre-commit hook or a GitHub Action. TruffleHog can also check whether a secret it finds still works. GitHub push protection rejects a push that contains a supported secret; its Supabase patterns include the secret key and personal access tokens, not the anon or publishable key.

Comparison

Supabase security tools, side by side

Free or paid and license are as each tool states them. A blank in a tool's docs is marked as not stated, not guessed.

All 15 tools in one table

Supabase security tools by layer, from each tool's own docs on 2026-10-22
Tool	Layer	What it catches	What it misses	Free or paid	Open source
VibeRaven	Code and migrations	Tables without RLS, using (true) policies, security definer functions anon can call, service role key in client code, unsigned Stripe webhooks	Live policies, dashboard changes, runtime behavior	Free CLI	Yes, MIT
rls-lint	Code and migrations	Tables created without RLS, using (true) or with check (true), grants of BYPASSRLS, FOR ALL policies	Anything outside migration files; it never connects to a database	Free	Yes, MIT
supabase-security	Code and migrations, and the live project	Tables with RLS off and anon grants, anon-callable security definer functions, public buckets; its live audit probes with your anon key	Storage RLS per object, and which tables you meant to be public (its README); alpha	Free	Yes, MIT
supabase db advisors --local	Code and migrations	The Advisor checks, such as missing RLS policies and exposed auth.users, on your local database after supabase db reset	Changes made on the live project	Free (Supabase CLI)	Public source, no license file
Supabase Security Advisor	Running database	RLS off in public, RLS with no policy, always-true policies, views and security definer functions anon can use	Migrations not applied yet; whether a policy returns the right rows	Built into Supabase	Lint SQL public in supabase/splinter, no license file
pgTAP	Running database	Whatever your tests assert, such as which rows a given user sees	Anything you have not written a test for	Free	Yes, PostgreSQL-style license
Supashield	Running database	Each role's allow or deny on tables and storage, against your policy.yaml; policy lint, coverage, drift	Access you have not listed as expected	Free	Yes, MIT
Supabomb	Running database, through the API	Tables, columns, RPC functions, buckets, edge functions and auth settings the anon key reaches; anon vs signed-in RLS	Source and migrations; for authorized testing only	Free	Public source, no license file
ZAP	Deployed app	Issues found by crawling and passive scanning; active attacks in a full scan; API scans from an OpenAPI or GraphQL definition	Source, migrations and policy text	Free	Yes, Apache-2.0
Vibe App Scanner	Deployed app	Missing RLS, and tables, buckets, RPC and edge functions reachable with the anon key, in 150+ checks	Source, migrations, vulnerable dependencies, secrets in git history (its own list)	First scan free, then paid plans	Not stated
RowShield	Deployed app	Tables the anon key can read, a service_role key in the client bundle; a daily audit once you connect a project	Before you connect: RLS off on a table, always-true policies, public buckets (its own list)	Free URL check and one project, then paid	Not stated
LeakScope	Deployed app	Exposed credentials, public data access, weak RLS, IDOR, JWT weaknesses, insecure headers	Source and migrations	Free light scan, no account; in beta	Not stated
Gitleaks	Secrets	Secrets in git history, folders and files, by pattern rule	Data access and RLS	Free; its GitHub Action needs a free key for organizations	CLI yes, MIT
TruffleHog	Secrets	Over 800 secret types, Supabase personal access tokens among them, and whether each still works	Data access and RLS	Free, with a paid enterprise product	Yes, AGPL-3.0
GitHub push protection	Secrets	Pushes that contain a supported secret, including a Supabase secret key or personal access token	The anon and publishable keys; a writer can bypass it with a reason	Free for public repos; private org repos need GitHub Secret Protection	No

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Which layer should I check first?

The running database. The Security Advisor ships with the Supabase platform and reads what is deployed, including changes made in the dashboard. Then add a migration check so the next change is caught before deploy, and a secret scanner, because Supabase's secret and service role keys bypass RLS.

Does a clean Security Advisor mean my RLS is right?

No. The Advisor runs fixed checks on your schema, and Supabase says some findings may be intentional. Whether a policy returns the right rows for each user takes a test that acts as that user: pgTAP with supabase test db, Supashield, or a request made as a second user on the deployed app.

Can a migration check see tables made in the Supabase dashboard?

No. Changes made on the remote database in the dashboard never reach your migration files. The Advisor, supabase-security's live audit and the outside scanners read the live project, so they see those tables.

Which tools cover which layer

Supabase security tools, side by side

All 15 tools in one table

Related guides

Sources behind this list

FAQ for builders before launch