For multi-tenant apps, RLS is enabled is not evidence that rows are isolated. The failure I keep looking for is simple: user A can read or mutate a row owned by tenant B through a permissive relationship or missing ownership condition.
I built a tiny red/green fixture around that exact case. The broken policy fails the cross-tenant assertion; the one-file fix passes the same test suite. It runs locally without a Supabase project, credentials, Docker, or production data:
https://github.com/cekuu35/supab...
My current minimum proof is: same-tenant access succeeds, cross-tenant read returns zero rows, cross-tenant write changes zero rows, and the assertions run under the application role rather than an admin role.
A tiny, runnable Supabase/Postgres security fixture that proves a policy can look correct and still leak rows across tenants. The same test suite runs red on the broken policy and green after the one-file fix. Start with npm ci && npm test—no Docker, cloud project, credentials, or production data required. Built for founders and developers who want evidence before shipping multi-tenant apps.
