Postgres Privilege Audit

Row-level security decides which rows a role sees. Grants decide which columns of those rows it sees, and which functions it may call. Most reviews, and most automated advisors, stop at the first question. The expensive defect lives in the second: a policy that correctly returns a row to its owner also returns every column on it, including the one value that authorizes a decision about that owner.

When the client holds a database role (Supabase, PostgREST, Hasura, any "the browser talks to Postgres" stack), grants are the API contract. So audit them the way you would audit an API: from what is actually deployed, per caller, per field, with a probe that acts as the caller.

Quick reference