Supabase Row-Level Security

Supabase is wonderful and dangerous in the same gesture. The anon API key in your client bundle is public — that's the design. The compensating control is Row-Level Security, a Postgres feature that enforces per-row visibility based on the requesting user's claims. Skip RLS on a table, and the anon key plus a curl command reads every row.

Supabase exposes Postgres tables as REST endpoints via PostgREST. A read from the anon role returns whatever rows the role's RLS policies allow. With RLS enabled and no policy granting SELECT, the table is empty to the anon role — safe. With RLS not enabled, the role's table-level GRANT decides — and Supabase's default GRANTs are permissive on the public schema. The result: an unenabled-RLS table is fully readable to any visitor.

Customer data leak: emails, profile info, orders, messages, anything in the unprotected table. If you're storing PII and don't have RLS, you have a GDPR breach the moment the table is enumerated. We've seen leaked Stripe customer IDs, password reset tokens, internal admin notes — all reachable with a single curl.

Enable Row-Level Security on every table in the public schema. Add explicit policies for the operations each role should be able to perform (SELECT, INSERT, UPDATE, DELETE) and what subset of rows they can touch. The Supabase dashboard surfaces RLS state per table — make 'all RLS enabled, no warnings' a deployment gate. Move sensitive data into a non-public schema where possible — `auth.users` is already there; consider doing the same for high-value tables. Audit your service-role key usage: anywhere the service role appears in a code path the user can influence is a vulnerability waiting to happen. Finally, rotate the anon key when staff turnover happens — yes, it's public, but the *project* binding makes the key uniquely identifying.

Supabase's security model is solid; its failures are operational. RLS on every table is the floor, not the ceiling.