The hook
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. We see this in roughly one in three Supabase apps we scan.
اهو ڪيئن ڪم ڪري ٿو
Supabase exposes Postgres tables as REST endpoints via PostgREST. A request like `GET /rest/v1/users?select=*` 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.
The blast radius
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.
// what fixvibe checks
What FixVibe checks
FixVibe checks backend-as-a-service exposure through safe configuration and access-boundary signals. Reports focus on what is exposed and how to lock it down. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
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.
The takeaway
Supabase's security model is solid; its failures are operational. RLS on every table is the floor, not the ceiling.