If you built a Supabase app quickly - with an AI coding tool or by hand - the row-level-security policies were often written last, or generated for you. That is fine. What is not fine is shipping without knowing whether those policies actually isolate one user's rows from another.
Supabase ships a database linter, and you should run it first - it is free and it catches the obvious cases: RLS switched off, and RLS switched on with no policy behind it. But a linter checks whether a policy exists, not whether the policy is correct. Those are different questions, and the second one is where cross-user leaks live.
The 2-second test
I put a minimal, synthetic reproduction on GitHub: supabase-rls-leak-demo. Same test suite on two branches, differing only by db/policies.sql:
broken -> 4 failed, 1 passed (an authenticated user reads another user's row)
