Start with the policy.
Row Level Security decides which rows a database role may read or change. Enabling RLS helps, but a policy using USING (true) can still allow every row for the roles it applies to.
Inspect the policy’s roles, command, USING expression and WITH CHECK expression. A public catalogue is different from a private customer profile: access must match the intended data.
Test without a session.
The Supabase public anon key is intended to be used in a browser. Treat it as public. The policies, rather than secrecy of that key, must limit data access.
OkToShip uses an approved table list and the public key to make bounded logged-out reads. A successful response with rows provides evidence of access. Metadata alone is labelled suspected when the intended access is uncertain.
Test a second account.
Logged-out denial does not prove users are isolated. A signed-in User B may still be able to request User A’s private row by changing an ID.
Create two dedicated test accounts, prepare test-owned rows and supply scoped reads. Fix the policy, then repeat the audit. Do not paste a Supabase service_role key into the client or into this audit connection.
Put it to the test.
Run an audit on an app you are authorized to test.