What it is
Your app stores records that belong to different people: their orders, their messages, their documents. Somewhere there needs to be a rule that says who is allowed to see and change which records. That rule has to live on your server or in your database, the parts users can’t touch. Anything decided on the user’s own device can be changed by the user.
AI tools often build the rule into the screen instead. The page only shows your records, so it looks right. But the request behind the page will hand over anyone’s records if you ask for them by number. If you use Supabase or something like it, the database has its own rules for this (it calls them row-level security), and it’s common for them to be missing, or switched on with a rule that lets everyone through.
What it looks like from your side
Nothing, until a user tells you. A customer emails a screenshot of someone else’s order. Someone changes the number at the end of a web address from 1042 to 1041 and sees another company’s invoice. Or nobody tells you, and it shows up later in a security questionnaire, or in a complaint.
What it costs if you ignore it
A privacy breach, even a small one, is a conversation with a lawyer. Depending on where your users are, you may be legally required to report it. It also ends deals: an enterprise buyer who finds this in a security review won’t sign.
And if the rule is missing for reading, it’s usually missing for changing too, so one user can edit or delete another’s data.
How to check it yourself in 30 seconds
- Sign in to your app and open something that belongs only to you, like an order, a project, or a profile page.
- Look at the address bar. If the address ends in a number or a code, change it by one and press Enter. If you have a second test account, sign in as that account and paste in the first account’s address instead.
- You should get an error or an empty page. If you see someone else’s record, that’s the finding.
- If your app uses Supabase, open your Supabase dashboard and click Table Editor. Each table shows whether row-level security is switched on. A table holding user data with it off, or with a rule that just says
true, is worth asking about.
Only do this with your own test accounts. Don’t go looking at real customers’ records to prove the point.
How I fix it
The rules move to where users can’t change them: the database or the server. Every table that holds user data gets a rule saying who can read and change each record, and every request for a record checks that the person asking is allowed.
Then I test it with two accounts trying to reach each other’s data, and those tests stay with your code so the rule can’t quietly disappear later.
Find out before your users do.
The Production Readiness Review is $250, takes 2–3 business days, and ends with a clear verdict: fix, restructure, or rebuild.
Book the $250 review