RLS & tenant isolation
Tables any logged-in user can read end to end.
Overview
lumioguard lists every table in your public schema, checks which ones have Row-Level Security off or a policy that scopes nothing, then cross-references your repo to confirm the app actually queries them. A table with RLS off that no code touches is noise; one your app reads is a cross-tenant leak.
What it looks for
- Tables with RLS disabled that application code reads or writes
- Anon-key clients querying an unprotected table — readable from any browser
- Tables queried by the app with no CREATE POLICY anywhere in migrations
- Policies using USING (true), or granted to anon and public with no row predicate
- Policies that check authentication but never scope rows to a tenant or owner
Why it matters
Without RLS, Postgres returns every row to anyone holding a valid key, and in a Supabase app that key is in the browser. This is the breach class behind CVE-2025-48757, and it is worse when RLS looks enabled: a policy of USING (true), or one that only checks the caller is logged in, passes every advisor while letting any authenticated user read every tenant’s rows.
Rules in this check
| What it reports | Fix path |
|---|---|
| RLS disabled on a table — cross-tenant rows accessible | Pull request |
| No RLS policy found for a queried table — lockout or bypass risk | Draft |
| Over-permissive RLS policy on a table — no tenant scoping | Pull request |
How the fixes arrive
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.