Scan rule · RSC-SEC-070
Signed-in strangers read other people's records
After domain verification, creates a throwaway account and counts how many rows that stranger sees in personal-data tables — without fetching a single row.
Why this matters
There are two entirely different questions, and AI-generated access rules regularly answer the wrong one. The first: is the caller signed in? The second: does this record belong to them? A policy with `auth.role() = 'authenticated'` answers only the first — and hands everyone who can register the data of everyone else.
From outside this is invisible, which is exactly why the mistake survives so long. Anonymously, the table answers with zero rows; every pure outside scan reports it as clean. Only a real account shows the difference — and an account that has just been created owns no data of its own. If it sees rows anyway, they necessarily belong to others. That is not an indication, it is proof.
Check it yourself: create a second account, sign in with it and open a list that should only show your own data. If entries from the first account appear, the separation is open. In SQL you recognise it by any policy whose `using` expression does not name the user.
Scan tier
How to fix it
Change policies to `auth.uid() = user_id` instead of `auth.role() = 'authenticated'`, then re-check.