Tagged auditing
2 pieces
- · 11 min read
The RLS Trap That Passes Every Test: A Postgres View Runs as Its Definer Unless You Say Otherwise
A Postgres view executes with its definer's privileges unless security_invoker is set, and that setting is off by default. Every view created before somebody thought about row-level security is therefore in the wrong mode, and the usual test, that a user sees their own data, passes identically in both modes. This explains the semantics, the migration problem, and the audit query that tells you which of your views are routing around the policy.
- · 11 min read
The Column List Matters as Much as the Rule: Row Policies Do Not Constrain Which Fields a User Can Write
A row-level security policy that lets a user update their own row is correct for a display name and catastrophic for a plan tier or a role. The policy decides which rows a write may touch. The damage comes from which columns. Self-escalation is a class of defect rather than a bug, and the controls that address it are column-level grants, a schema split between user-editable and system-owned fields, and an audit that fails when a new column appears.