Authenticated per-user check

The homepage scan proves what an anonymous visitor can read. This one goes deeper: it logs in as two of your own test users and checks whether one can read the other’s rows — the horizontal privilege-escalation (BOLA) class that stays invisible to an anonymous probe. Because it authenticates as a real user, it runs only on a domain you’ve verified.

Your site URL

Test user A

Password

Test user B (a different account)

Password

Use two distinct, already-confirmed logins (not the anon or service key). For the strongest signal, make sure both accounts own some representative data — a leak is proven by user A reading user B’s rows.

Passwords are exchanged for short-lived access tokens the moment you submit and are never stored. We read only as user A; user B is signed in only to learn its id.

Also test write-scoping (optional). If your policies allow it, we perform ONE value-neutral UPDATE per table — setting a row’s owner to the value it already has, changing no data — to prove whether a non-owner can write it. It is pinned to a single row, but a write still versions the row: it bumps updated_at, fires any triggers, and emits a Supabase Realtime event. Only enable this if you are authorized to modify this backend’s data.