Row-level security, or RLS, is the setting that decides whether a request for "row 42" gets checked against who's asking before the database hands it over. Without it, anyone who can reach your database can read or change any row — not because of a bug, but because that's what "off" means.
On a new table in Supabase, RLS is off by default. Plenty of apps get built, tested and launched by one person, who never sees the problem because they're always signed in as themselves. It shows up the day a second real customer's data becomes reachable by the first.
How to check it yourself
- 1Open your Supabase project and go to the Table Editor.
- 2Look at each table that holds customer data. There's an RLS toggle at the top — check whether it says enabled or disabled.
- 3If it's enabled, go to Authentication → Policies for that table and read what the policies actually say.
- 4A policy that reads as "true" for every row, for every user, is functionally the same as RLS being off. It's on, and it isn't protecting anything.
"Enabled with no policies" and "disabled" are opposite failure modes, both common. No policies means the database refuses every request, which usually gets "fixed" by adding a policy that allows everything — quietly recreating the disabled state under a setting that looks safe.
The test that actually proves it
Don't test this by clicking around your own app's interface — the interface only shows you the buttons you were given, which tells you nothing about what the database itself would hand over to a direct request. Create two accounts, put something in the first, sign in as the second, and try to reach the first account's data by changing an id in a direct API call. That's the only version of this test that tells you the truth.
If that test finds a gap, it's worth treating as urgent rather than something to schedule for later — this is the specific failure mode that lets one customer see another's data, which is the one that ends trust in a product rather than just costing it money.