RLS policy review

Nine judgments about one policy, in a single Jev request. These are the questions a rule-based lint cannot answer: a lint checks that RLS is on and that a policy exists, not whether the rule you wrote actually keeps one user out of another user’s rows.

expect failshape-identical
What this policy does

Same schema and same policy name as the baseline. Every signed-in user reads every row.

Why a linter can’t catch it

The bug is the right-hand side of the comparison: `is not null` where the correct version has `= user_id`. Both are a comparison on `auth.uid()`, so to a tool matching the shape of the code they look alike. The difference is that this one never mentions `user_documents.user_id`, the only column tying a row to a person — so the check really just means "are you logged in?", and every logged-in user reads every row. One lint does fire, `auth_rls_initplan`, but only about speed: it wants `auth.uid()` wrapped in a subquery. Apply its fix and you get `(select auth.uid()) is not null` — still the whole table, just computed once instead of once per row.

The safe version and the broken version are written the same way. A tool that matches patterns matches both.

Security Advisor says:auth_rls_initplan (PERF) — and its fix does not help
Paste a policy and its table, or load an example above.