Row-level security policies reduce cross-tenant data leaks compared with application-side filtering

Hypothesis

The row security documentation states that once row security is enabled on a table, all normal access must be allowed by a policy, and that without any policy a default-deny rule applies so that no rows are visible or modifiable; superusers, roles with BYPASSRLS and normally the table owner bypass it. A policy carries a USING expression for rows that may be seen and a WITH CHECK expression for rows that may be written; the CREATE POLICY page states that permissive policies are combined with OR, restrictive ones with AND, and that at least one permissive policy is needed before restrictive ones are useful. A service that connects as a non-owner role, sets the tenant per transaction (SET LOCAL app.tenant_id = ...) and defines USING (tenant_id = current_setting('app.tenant_id')::uuid) on every tenant table changes the failure modes: a query missing the tenant predicate still returns only the current tenant's rows, and a request that never sets app.tenant_id returns nothing or fails on the cast instead of returning every tenant's rows. The hypothesis: over the life of a codebase, this design yields fewer confirmed cross-tenant exposure bugs than application-side filtering with the same testing discipline.

Prediction

In codebases with policies on all tenant tables, bug reports classified as "data from another tenant visible" are rarer per endpoint than in comparable codebases without them, and the remaining leaks come from a small set of causes: connections running as owner, superuser or a BYPASSRLS role; tables where the policy was forgotten; and code that runs with the definer's privileges. Individual queries missing a predicate will not appear among the causes.

Proposed test

1. Select services of similar size with and without policy-based isolation; extract from their trackers the incidents tagged as cross-tenant exposure over a fixed period, normalised by number of endpoints.
2. Mutation-style check: remove the tenant predicate from a sample of queries in each codebase and count how many mutated queries return foreign rows in a test environment with two tenants, and how many tests catch them.
3. Record the residual failure classes to see whether owner connections and forgotten policies dominate, which would indicate where review effort belongs.

Status

No result is claimed. Policies move the failure mode but add their own: they must be created per table and tested, privileged roles bypass them, and policy expressions change query plans. The hypothesis concerns leak counts only, not performance or operational cost.