RLS coverage
Enumerate non-system tables and identify where Row Level Security is disabled or enabled with zero policies.
Supabase security
Supabase Security Scanner: Audit RLS, Policies, Advisors, and Secrets
A Supabase security audit should verify Row Level Security across every non-system table, inspect policy coverage and advisor findings, and check the connected repository for privileged credentials and risky migrations. Sentrail performs these checks read-only and puts any proposed change behind explicit human approval.
Reviewed by Sentrail · Updated August 17, 2026
Audit scope
What does a Supabase security scanner check?
A useful audit combines the live project's database posture with the application code that connects to it.
Policy posture
Surface policy coverage for review. Policy presence alone does not prove that ownership and tenant expressions are correct.
Supabase advisors
Read Supabase's security and performance advisor lints, including exposed views, definer functions, unsafe function search paths, and auth configuration findings.
Repository exposure
Search connected repositories for service-role credentials and other secrets in client-reachable files or public-prefixed environment variables.
Row Level Security
RLS coverage is the first question; policy correctness is the second.
Supabase browser clients commonly use the public anon key. That key is expected to be visible; the database's RLS policies are what constrain its data access. The service-role key is different: it bypasses RLS and must stay in trusted server-side environments.
An audit should distinguish tables with RLS off, tables with RLS on and no policies, and tables whose policies need contextual review. A permissive policy can be syntactically valid and operationally dangerous.
Public and anon keys
Expected in clients
Treat exposure as part of the Supabase client model, then verify that RLS and grants limit what the resulting role can access.
Service-role keys
Server only
Treat any client-reachable or committed service-role credential as high risk because it can bypass RLS.
Views and functions
Advisor evidence
Review exposed views, security-definer behavior, function search paths, and grants that can create paths around expected table policies.
Storage and APIs
Separate boundaries
Database-table coverage does not automatically validate Storage policies, custom APIs, Edge Functions, or every auth flow.
Read-only workflow
Connect, inspect, and report before proposing any change.
- Connect01
Authorize read access
Connect Supabase through OAuth and GitHub through the GitHub App so the audit can read current project and repository evidence.
- Inspect02
Run database and code checks
Collect RLS state, policy counts, advisor lints, auth posture, credential matches, and security-relevant migration context.
- Review03
Gate every remediation
Write a proposal with its scope and diff. Nothing changes until a reviewer approves; repository changes are draft pull requests only.
Migrations
Review schema changes as security changes.
Generated migrations can change grants, policies, functions, triggers, schemas, and exposed data paths even when the UI feature looks small.
- RLS enabled for each newly created client-facing table
- Select, insert, update, and delete policies match intended actors
- Ownership or tenant identifiers come from a trusted identity
- Security-definer functions have constrained search paths
- Grants do not expose unintended schemas or operations
- Service-role credentials never enter client code
- Advisor findings are reviewed after deployment
- A fresh audit runs against the resulting project state
Visible audit evidence
The result should show what was checked, not only a score.
CheckEvidenceResult
Database RLSLive projectCoverage + policy count
Supabase advisorsManagement APICurrent lints
Code and secretsGit commitRedacted findings
High-risk filesRepository contextReview notes
Illustrative representation of the evidence categories Sentrail records; not a customer result.
Audit the Supabase project you actually deploy.
Connect the live project and its repository, collect current RLS, advisor, secret, dependency, and deployment evidence, and keep every proposed fix under your control.