Supabase
Best Supabase security tools in 2026
Run Supabase's own Security Advisor first. It is free, built into the dashboard, and it catches the mistakes that cause most exposed Supabase databases. Everything else on this page exists to cover what the Advisor structurally cannot see.
Last reviewed April 20, 2026
The one distinction that matters
Schema-level tools read your database from the inside with full privileges. They tell you what your configuration says.
Deployed-app tools query from outside using your public anon key. They tell you what an anonymous visitor actually receives.
Those two answers disagree more often than people expect. A policy can look restrictive and still return rows.
At a glance
| Tool | Layer | Supabase-aware | Cost |
|---|---|---|---|
| Supabase Security Advisor | Schema | Yes | Free, built in |
| pgTAP via supabase test db | Schema | Yes | Free, open source |
| vas | Deployed app | Yes | Free first scan, paid plans after |
| Gitleaks | Repository | No | Free, open source |
| Semgrep | Source code | With custom rules | Free tier, paid for teams |
| CodeQL | Source code | With custom rules | Free for public repos |
| OWASP ZAP | Deployed app | No | Free, open source |
| Trivy | Dependencies | No | Free, open source |
What each tool catches, and what it misses
1Supabase Security Advisor
Every Supabase project, as the first thing you run
Catches
- Tables with RLS disabled
- RLS enabled but no policy attached
- SECURITY DEFINER views and functions
- Exposed auth schema and GraphQL surface
- Public storage buckets
Does not catch
It reads your database configuration from the inside. It cannot see what your deployed frontend exposes, which keys shipped in your bundle, or whether a policy that looks correct actually returns rows to an anonymous caller.
2pgTAP via supabase test db
Locking RLS behaviour down in CI so it cannot regress
Catches
- User A reading user B's rows
- Anonymous role reaching authenticated-only tables
- Policy regressions introduced by a migration
Does not catch
Only tests the cases you write. It proves the policies you thought of behave correctly, not that you thought of every table.
3vas
Checking what your live app actually exposes to the public anon key
Catches
- Tables, storage buckets, RPC functions and edge functions that answer the anon key
- service_role keys shipped in the frontend bundle
- Supabase config extracted from the live JS bundle, the same way anyone else can read it
- Missing security headers, and SPF/DMARC on the domain
Does not catch
It tests the deployed surface, not your source code or migrations. It will not find a vulnerable dependency, a logic bug in an edge function, or a secret committed to git history. Pair it with Gitleaks and a SAST tool.
4Gitleaks
Catching a service_role key or DB password before it reaches a commit
Catches
- SUPABASE_SERVICE_ROLE_KEY in source or .env files
- JWT secrets and database passwords
- Secrets buried in git history
Does not catch
Knows nothing about RLS. It also cannot tell a public anon key from a private one, so expect it to flag NEXT_PUBLIC_SUPABASE_ANON_KEY, which is safe by design.
5Semgrep
Custom rules in CI, for example banning service_role outside /server
Catches
- service_role client instantiated in client-side code
- Missing auth checks on route handlers
- Dangerous raw SQL construction
Does not catch
Pattern matching over source. It cannot evaluate whether a policy expression actually restricts the rows it appears to restrict.
6CodeQL
Deep data-flow bugs if your code is already on GitHub
Catches
- Injection and XSS
- Privilege escalation paths
- Unsafe data flow into queries
Does not catch
No understanding of Postgres RLS. Strong on application code, blind to database policy.
7OWASP ZAP
Generic web vulnerability testing before a release
Catches
- XSS and injection against the running app
- Missing headers
- Auth handling flaws
Does not catch
Treats PostgREST as an ordinary HTTP API. It will not enumerate your tables or reason about which ones should have been protected.
8Trivy
Known CVEs in packages and containers
Catches
- Vulnerable npm dependencies
- Container and IaC misconfiguration
- SBOM generation
Does not catch
Entirely unrelated to how your Supabase project is configured.
A stack that covers the gaps
No single tool covers a Supabase project. These four have almost no overlap, and three of them are free:
- 1Supabase Security Advisor for schema-level RLS and configuration, free
- 2pgTAP tests in CI for stops policy regressions, free
- 3Gitleaks for keeps service_role out of your repo, free
- 4An external scanner for tests what your deployed app exposes to the anon key
Add Semgrep or CodeQL if you want source-level analysis, and Trivy if you care about dependency CVEs. Neither is Supabase-specific.
Why the deployed-app check matters
Academic work on AI-generated applications has repeatedly found that code which is functionally correct is frequently still insecure, with missing access controls among the most common failures (see Understanding the (In)Security of Vibe-Coded Applications). That failure mode is invisible to a schema reader, because the schema is not what broke. The policy exists. It just does not do what its author believed.
The only way to settle it is to ask the deployed app the same question an attacker would, using the same public key they would use.
Test your deployed app
vas reads the Supabase config out of your live frontend, then queries every table, storage bucket, RPC function and edge function with your public anon key and reports what came back. Your first scan is free.
Common questions
What is the best Supabase security scanner?
Start with Supabase's own Security Advisor. It is free, built into the dashboard, and it catches the highest-severity configuration mistakes: tables with RLS disabled, RLS enabled with no policy attached, SECURITY DEFINER views, and public storage buckets. No third-party tool should be your first step, because none of them see your schema as directly. Add other tools to cover what the Advisor structurally cannot see, which is your deployed application.
If Supabase has a built-in Security Advisor, why would I need anything else?
The Advisor reads your database configuration from the inside, with full privileges. It tells you what your schema says. It cannot tell you what an anonymous visitor to your deployed site actually receives, which keys ended up in your JavaScript bundle, or whether a policy that looks restrictive returns rows in practice. Those are different questions and they need a tool that queries from outside with the public anon key.
Is there an open-source scanner that understands Supabase RLS?
Not really, and this is the honest gap in the ecosystem. The open-source security tools most often recommended for Supabase projects (Semgrep, CodeQL, Trivy, Gitleaks, OWASP ZAP) are general-purpose. They are good tools, but none of them model Row Level Security. The Supabase-aware options are Supabase's own Advisor and pgTAP tests for schema-level checks, and commercial scanners for the deployed-app side.
Do I need a paid tool at all?
For many projects, no. Supabase Security Advisor plus pgTAP tests in CI plus Gitleaks covers a large share of real risk and costs nothing. A paid external scanner earns its place when you want the deployed-app view, when you are shipping something with real user data, or when you want the check to run continuously rather than when you remember to look.
What is the most common Supabase security mistake?
A table that works perfectly in development because RLS was never switched on, then ships that way. Tables created through SQL migrations or the SQL editor do not get RLS enabled automatically, unlike tables created through the Table Editor. This single difference accounts for a large share of exposed Supabase databases.