Supabase RLS is enabled with real policies on every table

A Supabase table without row-level security is readable and writable by anyone who has the anon key — and the anon key ships in every client bundle by design. An attacker who opens devtools on the login page can pull the JWT, hit the REST endpoint directly, and dump or mutate the entire table. Firebase/Supabase misconfiguration incidents catalogued at appsecurity.net show a recurring pattern where RLS is either disabled outright or uses a permissive USING (true) policy, handing every table's contents to anyone with the anon key (which ships in the client bundle). AI coding tools routinely create tables with the Supabase CLI or dashboard without emitting the ENABLE ROW LEVEL SECURITY statement and without writing policies, because the default CREATE TABLE syntax doesn't require it. This is the single most common cause of public Supabase data leaks — the pattern has been behind dozens of disclosed incidents where customer emails, private messages, and payment records were scraped from production anon endpoints.

For each user table, add ALTER TABLE public.{table} ENABLE ROW LEVEL SECURITY; and define explicit policies. Without RLS, anyone with the anon key can read/write any row.

Deeper remediation guidance and cross-reference coverage for this check lives in the saas-authentication Pro audit — run that after applying this fix for a more exhaustive pass on the same topic.

• ID: supabase-rls-enabled-with-real-policies
• Severity: critical
• What to look for: Only run if Supabase is detected (via @supabase/supabase-js, @supabase/ssr, or supabase/ directory). Enumerate every .sql file in supabase/migrations/, supabase/schemas/, or any project-level migrations directory. Count occurrences of DISABLE ROW LEVEL SECURITY and ALTER TABLE ... DISABLE ROW LEVEL SECURITY. Then enumerate every CREATE TABLE statement and check whether each user-data table (anything not _meta/_audit/migrations) is followed by ENABLE ROW LEVEL SECURITY. Then enumerate every CREATE POLICY statement and inspect the USING and WITH CHECK clauses. A policy whose predicate is USING (true) or WITH CHECK (true) is categorically NOT a real policy — those predicates mean "no filter, match every row," which is functionally equivalent to no RLS at all when combined with the anon key. The failure patterns you must enumerate: USING (true), WITH CHECK (true), USING (1=1), USING (TRUE) (case-insensitive), and any policy that lacks a USING clause entirely (a policy with only WITH CHECK (...) filters writes but leaves reads fully open).
• Pass criteria: Zero DISABLE ROW LEVEL SECURITY statements AND every user-data table has a corresponding ENABLE ROW LEVEL SECURITY statement somewhere in migrations AND every CREATE POLICY statement has a non-trivial USING (or WITH CHECK, for insert-only policies) expression that references auth.uid(), auth.role(), auth.jwt(), a column comparison (e.g. user_id = auth.uid(), tenant_id = current_setting('...')), or a JOIN-derived predicate (e.g. EXISTS (SELECT 1 FROM memberships WHERE ...)). USING (true) and WITH CHECK (true) are categorically NOT real policies and do NOT count — no exceptions, unless the in-code waiver below is satisfied.
• In-code waiver: A USING (true) policy is acceptable if and ONLY if the immediately preceding line in the same .sql file is a comment matching ^-- INTENTIONALLY_PUBLIC: followed by at least one word explaining why the table is intentionally world-readable (e.g. -- INTENTIONALLY_PUBLIC: public marketing specials listing, no PII). The waiver must be on the line directly before the CREATE POLICY statement; comments on the table definition or on other lines do not count. When the waiver is present, the policy passes for that specific table. Count waived policies separately in the pass report.
• Fail criteria: At least one DISABLE ROW LEVEL SECURITY statement, OR at least one user-data CREATE TABLE without a matching ENABLE ROW LEVEL SECURITY, OR any policy whose only predicate is USING (true) / WITH CHECK (true) / USING (1=1) without the -- INTENTIONALLY_PUBLIC: waiver on the preceding line.
• Skip (N/A) when: Supabase is not detected. Quote the absence: "Supabase not detected: no @supabase/* dependency or supabase/ directory".
• Do NOT pass when: RLS is enabled in dev but commented out in prod migrations. A USING (true) policy does NOT count as a real policy — it matches every row and hands the table to anyone with the anon key. A policy that wraps true in extra syntax (e.g. USING ((true)), USING (TRUE), USING (1=1)) is the same failure in disguise and must also be flagged. A project-wide "lock everything down later" comment is not a waiver — the waiver must be -- INTENTIONALLY_PUBLIC: on the line directly before the specific permissive policy.
• Before evaluating, quote: Quote the full text of each CREATE POLICY statement (or the first 120 characters) so the USING/WITH CHECK predicate is visible. Quote the first 80 characters of any CREATE TABLE statement that lacks a paired ENABLE ROW LEVEL SECURITY. For any USING (true) policy, quote the line immediately preceding it to confirm whether the -- INTENTIONALLY_PUBLIC: waiver is present.
• Report even on pass: "Found N user tables in migrations; all N have ENABLE ROW LEVEL SECURITY. M policies total: K with real predicates (auth.uid / column comparison / JOIN), L with INTENTIONALLY_PUBLIC waiver, 0 with unwaived USING (true)."
• Detail on fail: "public.specials table has USING (true) policy without INTENTIONALLY_PUBLIC waiver (20260101_init.sql:47)" or "Table profiles created in 20260101_init.sql but no ENABLE ROW LEVEL SECURITY found" or "3 user tables with unwaived USING (true) policies: profiles, posts, messages".
• Cross-reference: For full auth coverage (signup, login, password-reset, MFA, session lifecycle), run the saas-authentication audit.
• Remediation: For each user table, add ALTER TABLE public.{table} ENABLE ROW LEVEL SECURITY; and define explicit policies. Without RLS, anyone with the anon key can read/write any row.