Supabase says row-level security is off
Your app ships a public key to every visitor’s browser. Row-level security is what stops that key reading every row of every table. Without it, anyone can.
What usually causes it
Tables created without RLS
Tables made in the SQL editor or by a migration start with row-level security off unless it is switched on.
Policies that allow everything
A policy written as “using (true)” turns RLS on and lets everyone through anyway.
The service role key in the browser
That key skips RLS entirely. If it is in your front-end code, the rules don’t matter.
What to check yourself
- In Supabase, open the Table Editor: tables without RLS are marked. The Security Advisor lists them too.
- Read each policy: who it lets read, insert, update and delete.
- Search your front-end code for the service role key; only the anon key belongs there.
What the free scan looks at
The scan looks for service role keys and other secrets in your code. Once you connect GitHub or upload your code, it also checks which tables the public key can read (by counting rows, never reading them) and which storage buckets anyone can list.
If you’d rather we fix it
App Rescue switches row-level security on with policies that fit your app, tests that each user sees only their own data, and moves secrets out of the browser. Production Ready goes on to cover the rest of the security checklist.
App Rescue, from €299 + VAT for a small app. The scan works out the exact price for yours.