Supabase row-level security: why AI skips it, how to find it, how to fix it

Supabase is Postgres with an auto-generated API in front of it. To let your frontend talk to that API, Supabase gives you a publishable 'anon' key — and it is genuinely meant to be public, embedded in your client code. The thing that makes that safe is row-level security: Postgres policies that run on every query and decide which rows this particular user is allowed to see or change. With RLS on and a policy like 'a user can only read rows where user_id equals their own id', the public key can't over-read.

With RLS off, there are no such rules, so the API happily returns everything. Anyone can open your app's network tab, copy the anon key and the request shape, and query the table directly for every row it holds — names, emails, whatever's in there. This is not an exotic attack; it's the default behaviour of a table with RLS disabled and a public key pointed at it.

Because the app works without it, and 'works' is what the generator is optimising for. When RLS is off, every query succeeds immediately — no policy to write, no 'permission denied' to debug, a preview that looks complete. Enabling RLS is the opposite experience: the moment you turn it on, queries start returning nothing until you write policies, which looks like you broke the app. A tool racing to a working preview takes the path that doesn't break, and that path is RLS-off.

The same logic explains the half-safe middle case, which a scan still catches: RLS enabled but with a permissive policy (`using (true)`) that allows everything. It silences the 'RLS is disabled' warning without actually restricting anything — security theatre that reads as secure in a glance and isn't.

The check has to cover every table, because RLS is per-table — one unprotected table is enough to leak. The quickest sweep is a scan: paste the repo into secure·vibes and missing-RLS and permissive-policy issues surface as auth & access-control findings, each with the file, the table, and a fix prompt. To verify by hand, open the Supabase dashboard's Authentication → Policies view and confirm every table shows RLS enabled with at least one real, user-scoped policy — not zero policies, and not a blanket `true`.

Fixing is enabling RLS on the table, then adding policies that constrain by the authenticated user (typically `auth.uid() = user_id`) for each operation you allow. Do it table by table, test that legitimate queries still work for a signed-in user, and confirm they return nothing for a different user. If the anon key was ever public with RLS off, treat the data as already readable and act accordingly — RLS stops future over-reads, it doesn't retract past ones.