@safegres/test 0.0.2 → 1.30.7

package/esm/checks/view-exposure.js

@@ -0,0 +1,231 @@
+/**
+ * L11 and L12: the two things a *readable* view does that its owner and its
+ * body, taken separately, do not explain.
+ *
+ * **L11 — a materialized view is a snapshot, not a query.** Its rows were
+ * computed once, by whoever ran `REFRESH`, and are then handed to every reader
+ * of the matview verbatim. The base relations are not consulted at read time,
+ * so their ACLs never apply and — the part that matters — their RLS policies
+ * never run. A matview cannot carry policies of its own either: RLS attaches
+ * to tables, and `security_invoker` is a view-only reloption. So a SELECT
+ * grant on a matview over an RLS-protected table is an unconditional grant on
+ * the rows that were visible at refresh time.
+ *
+ * **L12 — a view's `WHERE` is a filter, not a boundary.** Without
+ * `security_barrier` the planner may push the *caller's* qual below the view's
+ * own, so a leaky operator or a `COST 0.0001` function evaluates against rows
+ * the view was written to hide. The rows are not returned, but they are seen —
+ * and a function that raises them, writes them, or times differently on them
+ * exfiltrates them. This only matters where the view is the only path to the
+ * relation; if the caller can read the base table directly there is nothing
+ * for the view to hide.
+ *
+ * Both ship the same way as the rest of the L-series: `info`, score-neutral,
+ * and never recommending a revoke. The remedies are properties of the view.
+ */
+import { bodyFiltersRows } from '../callgraph/extract';
+import { buildRelationIndex, readBodies, resolveViewBases } from './definer-view';
+import { effectiveGrants } from './lattice';
+import { computeViewReach } from './role-reach';
+/**
+ * Resolve both populations in one pass over the view bodies.
+ *
+ * A materialized view is deliberately absent from the relation index: it is a
+ * terminal relation for anything reading *through* it (its rows are stored),
+ * so it must never be followed as a nested view. Its own body is still read,
+ * to learn which relations the refresh copied from.
+ */
+export async function analyzeViewExposure(views, tables) {
+    const queryable = views.filter((v) => !v.materialized);
+    const index = buildRelationIndex(queryable, tables);
+    const bodies = await readBodies(views);
+    const matviews = [];
+    const leaky = [];
+    const suppressed = [];
+    for (const view of views) {
+        const label = `${view.schema}.${view.name}`;
+        if (view.materialized) {
+            const { bases, opaque } = resolveViewBases(view, index, bodies);
+            if (opaque) {
+                suppressed.push({ view: label, reason: opaque });
+                continue;
+            }
+            // Relations outside the audited schemas carry no ACL or policy to
+            // compare the stored rows against; L14 reports the reach instead.
+            const graded = bases.filter((b) => !b.external);
+            if (graded.length === 0)
+                continue;
+            matviews.push({
+                schema: view.schema,
+                name: view.name,
+                owner: view.owner,
+                grants: view.grants,
+                baseRelations: graded,
+                materialized: true
+            });
+            continue;
+        }
+        // An invoker view confers nothing, so its `WHERE` is never the only thing
+        // standing between a caller and a relation: the caller needs its own
+        // grant on the base to read the view at all.
+        if (view.securityInvoker || view.securityBarrier)
+            continue;
+        const filters = await bodyFiltersRows(view.definition);
+        if (filters === null) {
+            suppressed.push({ view: label, reason: 'body could not be parsed to look for a row filter' });
+            continue;
+        }
+        if (!filters)
+            continue;
+        const { bases, opaque } = resolveViewBases(view, index, bodies);
+        if (opaque) {
+            suppressed.push({ view: label, reason: opaque });
+            continue;
+        }
+        const gradedBases = bases.filter((b) => !b.external);
+        if (gradedBases.length === 0)
+            continue;
+        leaky.push({
+            schema: view.schema,
+            name: view.name,
+            owner: view.owner,
+            grants: view.grants,
+            baseRelations: gradedBases
+        });
+    }
+    return { matviews, leaky, suppressed };
+}
+/** Is `role` actually filtered by `table`'s policies? */
+function subjectToRls(table, role, graph) {
+    if (!table.rlsEnabled)
+        return false;
+    if (graph.get(role)?.bypassRls)
+        return false;
+    // The owner is exempt unless the table FORCEs policies on itself.
+    return !(table.owner === role && !table.rlsForced);
+}
+/**
+ * L11: an untrusted role reads a table's rows out of a materialized view.
+ *
+ * Fires where the role can SELECT the matview and either holds no SELECT on
+ * the relation the refresh read, or holds one but is subject to policies the
+ * stored rows never passed through. The second case is the one catalog-only
+ * analysis is worst at: the ACL says the role may read the table, RLS says it
+ * may read three rows of it, and the matview hands it all of them.
+ */
+export function checkMatviewSnapshot(matviews, tables, graph, options = {}) {
+    const untrusted = options.roles ?? [];
+    if (untrusted.length === 0 || matviews.length === 0)
+        return [];
+    const byKey = new Map(tables.map((t) => [`${t.schema}.${t.name}`, t]));
+    const out = [];
+    for (const { role, cells } of computeViewReach(matviews, graph, untrusted)) {
+        for (const cell of cells) {
+            const base = byKey.get(`${cell.schema}.${cell.table}`);
+            if (!base)
+                continue;
+            const hasSelect = effectiveGrants(base, role, graph).some((g) => g.privilege === 'SELECT');
+            const filtered = subjectToRls(base, role, graph);
+            // Reachable in its own right and not row-filtered: the snapshot shows
+            // the role nothing it could not select from the table itself.
+            if (hasSelect && !filtered)
+                continue;
+            const matview = cell.path.find((e) => e.kind === 'matview');
+            if (!matview)
+                continue;
+            const refresher = cell.effectiveRole;
+            out.push({
+                code: 'L11',
+                severity: 'info',
+                category: 'anti-pattern',
+                schema: base.schema,
+                table: base.name,
+                role,
+                privilege: 'SELECT',
+                message: hasSelect
+                    ? `Untrusted role ${role} reads ${base.schema}.${base.name} through materialized view `
+                        + `${matview.view} without the row filter its policies apply — the rows were stored by `
+                        + `${refresher} at REFRESH time`
+                    : `Untrusted role ${role} reads ${base.schema}.${base.name} through materialized view `
+                        + `${matview.view}, which stores rows computed as ${refresher} — ${role} holds no SELECT `
+                        + `on the base relation`,
+                hint: `A materialized view is a stored copy: reading it never consults ${base.schema}.`
+                    + `${base.name}, so neither its grants nor its RLS policies apply, and the matview cannot `
+                    + `carry policies or \`security_invoker\` of its own. Replace it with a plain `
+                    + `\`security_invoker\` view if the freshness is not what it is for, materialize only the `
+                    + `columns and rows that are safe to hand out unconditionally, or keep it in a schema the `
+                    + `API does not expose and serve a filtered view from it. Do not revoke the SELECT on the `
+                    + `matview — that grant is what the API serves.`,
+                context: {
+                    matview: matview.view,
+                    effectiveRole: refresher,
+                    baseRlsEnabled: base.rlsEnabled,
+                    rlsBypassed: filtered,
+                    holdsBaseSelect: hasSelect,
+                    proof: cell.proof
+                }
+            });
+        }
+    }
+    return out;
+}
+/**
+ * L12: a definer view filters rows for an untrusted role but is not a barrier.
+ *
+ * Fires where the role reaches a relation *only* through a view whose body has
+ * a `WHERE`, and the view is not `security_barrier`. The finding is about the
+ * rows the view excludes: they are the ones the author meant to withhold, and
+ * without the barrier a cheap leaky qual supplied by the caller is evaluated
+ * against them.
+ */
+export function checkLeakyFilterView(views, tables, graph, options = {}) {
+    const untrusted = options.roles ?? [];
+    if (untrusted.length === 0 || views.length === 0)
+        return [];
+    const byKey = new Map(tables.map((t) => [`${t.schema}.${t.name}`, t]));
+    const out = [];
+    for (const { role, cells } of computeViewReach(views, graph, untrusted)) {
+        for (const cell of cells) {
+            if (cell.effectiveRole === role)
+                continue;
+            const base = byKey.get(`${cell.schema}.${cell.table}`);
+            if (!base)
+                continue;
+            // The caller can read the relation directly, so the view's WHERE is a
+            // convenience, not a boundary, and pushing a qual past it reveals
+            // nothing new.
+            if (effectiveGrants(base, role, graph).some((g) => g.privilege === 'SELECT'))
+                continue;
+            const hops = cell.path.filter((e) => e.kind === 'view');
+            const outermost = hops[0];
+            if (!outermost)
+                continue;
+            out.push({
+                code: 'L12',
+                severity: 'info',
+                category: 'anti-pattern',
+                schema: base.schema,
+                table: base.name,
+                role,
+                privilege: 'SELECT',
+                message: `View ${outermost.view} is the only path untrusted role ${role} has to `
+                    + `${base.schema}.${base.name}, and its row filter is not a security barrier — a leaky `
+                    + `qual from ${role} can be evaluated against the rows the view excludes`,
+                hint: `Recreate the view \`WITH (security_barrier = true)\` so the planner cannot push a `
+                    + `caller-supplied qual below its own \`WHERE\`. A cheap function or a leaky operator is `
+                    + `otherwise evaluated on every row of ${base.schema}.${base.name}, including the hidden `
+                    + `ones, which is enough to read them out through errors, notices or timing. Where the `
+                    + `filter is per-caller, an RLS policy on the base relation is the stronger form — policy `
+                    + `quals already get barrier treatment. Do not revoke the SELECT on the view.`,
+                context: {
+                    view: outermost.view,
+                    effectiveRole: cell.effectiveRole,
+                    viaViews: hops.map((h) => h.view),
+                    baseRlsEnabled: base.rlsEnabled,
+                    proof: cell.proof
+                }
+            });
+        }
+    }
+    return out;
+}

package/esm/checks/view-writes.d.ts

@@ -0,0 +1,88 @@
+/**
+ * L9, L10 and L18: what a view does *beyond* its SELECT.
+ *
+ * L8 models the read edge — a non-`security_invoker` view hands its readers
+ * the owner's privileges on the relations its body names. Two write paths
+ * escape that model entirely, and both were verified against PostgreSQL 18
+ * rather than inferred:
+ *
+ *   - **L9, auto-update.** A simple view is updatable: Postgres rewrites an
+ *     INSERT/UPDATE/DELETE on the view onto its single base relation. On a
+ *     definer view that rewrite is permission-checked against the *owner*, so
+ *     INSERT on the view is INSERT on the base table the caller cannot touch.
+ *     `security_invoker = true` closes it (the write is then checked against
+ *     the caller and denied). The body alone cannot prove the write lands:
+ *     `pg_relation_is_updatable` is the catalog half of the proof.
+ *
+ *   - **L10, rewrite rules.** A rule other than the view's own `_RETURN` rule
+ *     is invisible to `pg_get_viewdef`: `ON INSERT ... DO INSTEAD INSERT INTO
+ *     audit` writes a relation the view body never names. Rule actions are
+ *     checked against the rule's table owner, and — unlike the view's own base
+ *     relations — `security_invoker` does **not** govern them. An invoker view
+ *     with such a rule still writes `audit` as the view owner.
+ *
+ *   - **L18, an unchecked write.** `WITH CHECK OPTION` is not the default, so
+ *     a view whose `WHERE` decides which rows a role may *see* says nothing
+ *     about which rows it may *write*: `INSERT INTO tenant_rows VALUES (...)`
+ *     through a `WHERE tenant_id = current_tenant()` view stores a row for
+ *     another tenant, which the writer then cannot see. It is the write-side
+ *     twin of L12 — the view's filter is a read filter, not a boundary.
+ *
+ * All three keep L8's conservatism. An `INSTEAD OF` trigger sends the write into a
+ * function body, which auto-update cannot place and L20 follows instead
+ * (`definer-function.ts`); a multi-relation body
+ * is not auto-updatable in a way we can pin to one target, and an unreadable
+ * rule action is unknown — all three suppress rather than guess. And, as in
+ * L8, the fix is never a revoke: the grant on the view is what the API serves.
+ */
+import type { ViewSnapshot } from '../pg/indexes';
+import type { TableSnapshot } from '../pg/introspect';
+import type { Finding } from '../types';
+import { type SuppressedView } from './definer-view';
+import { type LatticeRoleOptions, type RoleGraph } from './lattice';
+import { type ViewWriteInput } from './role-reach';
+export interface ViewWriteAnalysis {
+    /** Definer views whose writes are auto-rewritten onto a base relation. */
+    autoUpdatable: ViewWriteInput[];
+    /** Views carrying rewrite rules whose actions reach other relations. */
+    ruleDriven: ViewWriteInput[];
+    /**
+     * The subset of {@link autoUpdatable} whose body filters rows and which
+     * carries no `WITH CHECK OPTION` — L18 inputs.
+     */
+    unchecked: ViewWriteInput[];
+    /** Views deliberately left out, with why. */
+    suppressed: SuppressedView[];
+}
+/**
+ * Resolve, for every view in the snapshot, the relations a write against it
+ * actually lands on — through auto-update rewriting and through rewrite rules.
+ */
+export declare function analyzeViewWrites(views: ViewSnapshot[], tables: TableSnapshot[]): Promise<ViewWriteAnalysis>;
+/**
+ * L9: an untrusted role writes a base relation through an auto-updatable
+ * definer view.
+ *
+ * Fires once per (role, view, base relation, command) where the role holds
+ * the command on the view, the view executes as someone else, and the role
+ * holds no such privilege on the relation the write lands on.
+ */
+export declare function checkDefinerViewWrite(views: ViewWriteInput[], tables: TableSnapshot[], graph: RoleGraph, options?: LatticeRoleOptions): Finding[];
+/**
+ * L10: an untrusted role writes a relation through a rewrite rule on a view.
+ *
+ * Unlike L9 this fires on `security_invoker` views too: `security_invoker`
+ * governs the view's own base relations, not the relations a rule's actions
+ * name, which are checked against the rule's table owner either way.
+ */
+export declare function checkViewRuleBypass(views: ViewWriteInput[], tables: TableSnapshot[], graph: RoleGraph, options?: LatticeRoleOptions): Finding[];
+/**
+ * L18: an untrusted role writes rows a filtering view will not show it.
+ *
+ * Fires on the L9 population narrowed to filtering views with no `WITH CHECK
+ * OPTION`, minus DELETE — which removes rows the view already showed rather
+ * than producing new ones. It overlaps L9 by design and answers a different
+ * question: L9 is *whether* the role can write the relation at all, L18 is
+ * whether the view's own condition constrains what it writes.
+ */
+export declare function checkUncheckedViewWrite(views: ViewWriteInput[], tables: TableSnapshot[], graph: RoleGraph, options?: LatticeRoleOptions): Finding[];

package/esm/checks/view-writes.js

@@ -0,0 +1,344 @@
+/**
+ * L9, L10 and L18: what a view does *beyond* its SELECT.
+ *
+ * L8 models the read edge — a non-`security_invoker` view hands its readers
+ * the owner's privileges on the relations its body names. Two write paths
+ * escape that model entirely, and both were verified against PostgreSQL 18
+ * rather than inferred:
+ *
+ *   - **L9, auto-update.** A simple view is updatable: Postgres rewrites an
+ *     INSERT/UPDATE/DELETE on the view onto its single base relation. On a
+ *     definer view that rewrite is permission-checked against the *owner*, so
+ *     INSERT on the view is INSERT on the base table the caller cannot touch.
+ *     `security_invoker = true` closes it (the write is then checked against
+ *     the caller and denied). The body alone cannot prove the write lands:
+ *     `pg_relation_is_updatable` is the catalog half of the proof.
+ *
+ *   - **L10, rewrite rules.** A rule other than the view's own `_RETURN` rule
+ *     is invisible to `pg_get_viewdef`: `ON INSERT ... DO INSTEAD INSERT INTO
+ *     audit` writes a relation the view body never names. Rule actions are
+ *     checked against the rule's table owner, and — unlike the view's own base
+ *     relations — `security_invoker` does **not** govern them. An invoker view
+ *     with such a rule still writes `audit` as the view owner.
+ *
+ *   - **L18, an unchecked write.** `WITH CHECK OPTION` is not the default, so
+ *     a view whose `WHERE` decides which rows a role may *see* says nothing
+ *     about which rows it may *write*: `INSERT INTO tenant_rows VALUES (...)`
+ *     through a `WHERE tenant_id = current_tenant()` view stores a row for
+ *     another tenant, which the writer then cannot see. It is the write-side
+ *     twin of L12 — the view's filter is a read filter, not a boundary.
+ *
+ * All three keep L8's conservatism. An `INSTEAD OF` trigger sends the write into a
+ * function body, which auto-update cannot place and L20 follows instead
+ * (`definer-function.ts`); a multi-relation body
+ * is not auto-updatable in a way we can pin to one target, and an unreadable
+ * rule action is unknown — all three suppress rather than guess. And, as in
+ * L8, the fix is never a revoke: the grant on the view is what the API serves.
+ */
+import { bodyFiltersRows, extractAccess, extractQuery } from '../callgraph/extract';
+import { buildRelationIndex, resolveRelation } from './definer-view';
+import { effectiveGrants } from './lattice';
+import { computeViewWriteReach } from './role-reach';
+/** How deep a chain of updatable views on views is followed before giving up. */
+const MAX_VIEW_DEPTH = 8;
+/**
+ * Resolve, for every view in the snapshot, the relations a write against it
+ * actually lands on — through auto-update rewriting and through rewrite rules.
+ */
+export async function analyzeViewWrites(views, tables) {
+    const queryable = views.filter((v) => !v.materialized);
+    const index = buildRelationIndex(queryable, tables);
+    const autoUpdatable = [];
+    const ruleDriven = [];
+    const unchecked = [];
+    const suppressed = [];
+    for (const view of queryable) {
+        const name = `${view.schema}.${view.name}`;
+        const auto = await autoUpdateEdges(view, index, suppressed);
+        if (auto.length > 0) {
+            const input = {
+                schema: view.schema,
+                name: view.name,
+                owner: view.owner,
+                grants: view.grants,
+                writeEdges: auto
+            };
+            autoUpdatable.push(input);
+            if (view.checkOption === 'none') {
+                // A view with no `WHERE` excludes no rows, so there is nothing a write
+                // could land outside of; an unparseable body is unknown, not clean.
+                const filters = await bodyFiltersRows(view.definition);
+                if (filters === null) {
+                    suppressed.push({
+                        view: name,
+                        reason: 'body could not be parsed to look for a row filter'
+                    });
+                }
+                else if (filters) {
+                    // WITH CHECK OPTION constrains the rows a write *produces*, so only
+                    // the commands that produce rows can escape it.
+                    const writes = auto.filter((e) => e.privilege !== 'DELETE');
+                    if (writes.length > 0)
+                        unchecked.push({ ...input, writeEdges: writes });
+                }
+            }
+        }
+        const fromRules = [];
+        for (const rule of view.rules) {
+            if (rule.event === 'SELECT')
+                continue;
+            const edges = await ruleEdges(view, rule, index);
+            if (edges === null) {
+                suppressed.push({
+                    view: name,
+                    reason: `rule ${rule.name} has an action this analysis cannot follow`
+                });
+                continue;
+            }
+            fromRules.push(...edges);
+        }
+        if (fromRules.length > 0) {
+            ruleDriven.push({
+                schema: view.schema,
+                name: view.name,
+                owner: view.owner,
+                grants: view.grants,
+                writeEdges: fromRules
+            });
+        }
+    }
+    return { autoUpdatable, ruleDriven, unchecked, suppressed };
+}
+/**
+ * The base relation an auto-updatable definer view's writes are rewritten
+ * onto, if it can be proven.
+ *
+ * Auto-update only applies when nothing else has taken over the write path,
+ * so a view with rules or `INSTEAD OF` triggers is not handled here — the
+ * catalog's updatability bitmask counts those too, and attributing their
+ * writes to the body's relation would be a guess.
+ */
+async function autoUpdateEdges(view, index, suppressed) {
+    const name = `${view.schema}.${view.name}`;
+    if (view.securityInvoker)
+        return []; // the write is checked against the caller
+    if (view.writable.length === 0)
+        return [];
+    if (view.insteadOfTriggers) {
+        suppressed.push({
+            view: name,
+            reason: 'INSTEAD OF triggers decide where the write lands, in a trigger function body — L20, not auto-update'
+        });
+        return [];
+    }
+    if (view.rules.some((r) => r.event !== 'SELECT'))
+        return []; // rule path, see ruleEdges
+    const hops = [{ view: name, owner: view.owner }];
+    let current = view;
+    for (;;) {
+        if (hops.length > MAX_VIEW_DEPTH) {
+            suppressed.push({ view: name, reason: `view chain deeper than ${MAX_VIEW_DEPTH} hops` });
+            return [];
+        }
+        const body = await extractQuery(current.definition);
+        if (body.opaque) {
+            suppressed.push({ view: name, reason: body.opaqueReason ?? 'body could not be read' });
+            return [];
+        }
+        const resolved = body.tables
+            .map((ref) => resolveRelation(ref, current.schema, index))
+            .filter((r) => r !== null);
+        // Auto-update needs exactly one target. Anything else — a join, a body
+        // whose references we could not pin down — is not a write we can place.
+        if (resolved.length !== 1)
+            return [];
+        const target = resolved[0];
+        // A relation outside the audited schemas cannot be graded: its owner, its
+        // ACL and its RLS are all unknown, so the write is not placeable here.
+        if (target.kind === 'external')
+            return [];
+        if (target.kind === 'table') {
+            return view.writable.map((privilege) => ({
+                schema: target.schema,
+                table: target.name,
+                via: privilege,
+                privilege,
+                hops: [...hops]
+            }));
+        }
+        const nested = target.view;
+        if (`${nested.schema}.${nested.name}` === `${current.schema}.${current.name}`)
+            return [];
+        if (nested.materialized || nested.insteadOfTriggers)
+            return [];
+        // The inner view re-owns the write unless it defers to the caller, in
+        // which case whichever owner is already in force stays in force.
+        const owner = nested.securityInvoker ? hops[hops.length - 1].owner : nested.owner;
+        hops.push({ view: `${nested.schema}.${nested.name}`, owner });
+        current = nested;
+    }
+}
+/**
+ * The relations a rewrite rule's actions reach, or `null` when the action
+ * cannot be followed.
+ *
+ * The rule's own view is dropped from the result: `pg_get_ruledef` names it in
+ * the `ON ... TO <view>` clause, and that reference is the trigger, not a
+ * target. `DO INSTEAD NOTHING` therefore yields nothing at all, which is the
+ * correct answer for a read-only view — the commonest rule in the wild.
+ */
+async function ruleEdges(view, rule, index) {
+    const self = `${view.schema}.${view.name}`;
+    const { accesses, opaque } = await extractAccess(rule.definition);
+    if (opaque)
+        return null;
+    const edges = [];
+    for (const access of accesses) {
+        // Reads inside a rule action are the view's own SELECT path, which L8
+        // already models; the escalation a rule adds is the write.
+        if (access.privilege === 'SELECT')
+            continue;
+        const target = resolveRelation(access, view.schema, index);
+        if (!target)
+            continue;
+        if (target.kind === 'external')
+            continue;
+        if (target.kind === 'view') {
+            // The write recurses into another view's rewrite path; proving where it
+            // finally lands is more than this analysis can do.
+            return null;
+        }
+        if (`${target.schema}.${target.name}` === self)
+            continue;
+        edges.push({
+            schema: target.schema,
+            table: target.name,
+            via: rule.event,
+            privilege: access.privilege,
+            hops: [{ view: self, owner: view.owner }],
+            rule: rule.name
+        });
+    }
+    return edges;
+}
+/**
+ * L9: an untrusted role writes a base relation through an auto-updatable
+ * definer view.
+ *
+ * Fires once per (role, view, base relation, command) where the role holds
+ * the command on the view, the view executes as someone else, and the role
+ * holds no such privilege on the relation the write lands on.
+ */
+export function checkDefinerViewWrite(views, tables, graph, options = {}) {
+    return writeFindings(views, tables, graph, options, 'L9', (ctx) => ({
+        message: `Untrusted role ${ctx.role} can ${ctx.privilege} ${ctx.target} through view ${ctx.view}, `
+            + `which executes as its owner ${ctx.owner} — ${ctx.role} holds no ${ctx.privilege} on the `
+            + `base relation`
+            + (ctx.rlsBypassed ? `, and ${ctx.owner} is not subject to its RLS policies` : ''),
+        hint: `The view is auto-updatable, so Postgres rewrites the ${ctx.privilege} onto ${ctx.target} and `
+            + `checks it against ${ctx.owner}, not ${ctx.role}. Recreate the view `
+            + `\`WITH (security_invoker = true)\` so the caller's own grants and policies apply, give it an `
+            + `owner whose reach matches what the view is meant to expose, or make it non-updatable. Do not `
+            + `revoke the grant on the view — that grant is what the API serves.`
+    }));
+}
+/**
+ * L10: an untrusted role writes a relation through a rewrite rule on a view.
+ *
+ * Unlike L9 this fires on `security_invoker` views too: `security_invoker`
+ * governs the view's own base relations, not the relations a rule's actions
+ * name, which are checked against the rule's table owner either way.
+ */
+export function checkViewRuleBypass(views, tables, graph, options = {}) {
+    return writeFindings(views, tables, graph, options, 'L10', (ctx) => ({
+        message: `Untrusted role ${ctx.role} can ${ctx.privilege} ${ctx.target} through rule ${ctx.rule} on view `
+            + `${ctx.view} — the rule's action runs as the view owner ${ctx.owner}, and ${ctx.role} holds no `
+            + `${ctx.privilege} on ${ctx.target}`
+            + (ctx.rlsBypassed ? `, whose RLS policies ${ctx.owner} is not subject to` : ''),
+        hint: `Rewrite rules are not shown by \`pg_get_viewdef\` and are not governed by \`security_invoker\`: `
+            + `their actions are permission-checked against the owner of the relation the rule is on. Move `
+            + `the action into a function the caller must be granted EXECUTE on, or give the view an owner `
+            + `whose reach matches what the rule is meant to do. Do not revoke the grant on the view — that `
+            + `grant is what the API serves.`
+    }));
+}
+/**
+ * L18: an untrusted role writes rows a filtering view will not show it.
+ *
+ * Fires on the L9 population narrowed to filtering views with no `WITH CHECK
+ * OPTION`, minus DELETE — which removes rows the view already showed rather
+ * than producing new ones. It overlaps L9 by design and answers a different
+ * question: L9 is *whether* the role can write the relation at all, L18 is
+ * whether the view's own condition constrains what it writes.
+ */
+export function checkUncheckedViewWrite(views, tables, graph, options = {}) {
+    return writeFindings(views, tables, graph, options, 'L18', (ctx) => ({
+        message: `Untrusted role ${ctx.role} can ${ctx.privilege} rows into ${ctx.target} through view `
+            + `${ctx.view} that the view's own row filter excludes — the view has no WITH CHECK OPTION, `
+            + `so its \`WHERE\` governs reads only`,
+        hint: `Recreate the view \`WITH LOCAL CHECK OPTION\` (or \`CASCADED\`, to enforce every underlying `
+            + `view's condition too) so a row written through it must satisfy the condition it is served `
+            + `under. Where the filter is per-caller, an RLS policy with a \`WITH CHECK\` clause on `
+            + `${ctx.target} is the stronger form — it applies however the row arrives. Do not revoke the `
+            + `${ctx.privilege} on the view; that grant is what the API serves.`
+    }));
+}
+function writeFindings(views, tables, graph, options, code, render) {
+    const untrusted = options.roles ?? [];
+    if (untrusted.length === 0 || views.length === 0)
+        return [];
+    const byKey = new Map(tables.map((t) => [`${t.schema}.${t.name}`, t]));
+    const out = [];
+    for (const { role, cells } of computeViewWriteReach(views, graph, untrusted)) {
+        for (const cell of cells) {
+            if (cell.effectiveRole === role)
+                continue;
+            const base = byKey.get(`${cell.schema}.${cell.table}`);
+            if (!base)
+                continue;
+            const privilege = cell.privileges[0];
+            // Already writable in its own right: the view launders nothing.
+            if (effectiveGrants(base, role, graph).some((g) => g.privilege === privilege))
+                continue;
+            const viewHops = cell.path.filter((e) => e.kind === 'view');
+            const ruleEdge = cell.path.find((e) => e.kind === 'rule');
+            const grantEdge = cell.path.find((e) => e.kind === 'grant');
+            const owner = cell.effectiveRole;
+            const ownerAttrs = graph.get(owner);
+            const rlsBypassed = base.rlsEnabled
+                && (!!ownerAttrs?.bypassRls || (base.owner === owner && !base.rlsForced));
+            const target = `${base.schema}.${base.name}`;
+            const { message, hint } = render({
+                role,
+                view: viewHops[0].view,
+                owner,
+                target,
+                privilege,
+                ...(ruleEdge ? { rule: ruleEdge.rule } : {}),
+                rlsBypassed
+            });
+            out.push({
+                code,
+                severity: 'info',
+                category: 'anti-pattern',
+                schema: base.schema,
+                table: base.name,
+                role,
+                privilege,
+                message,
+                hint,
+                context: {
+                    view: viewHops[0].view,
+                    effectiveRole: owner,
+                    viaViews: viewHops.map((h) => h.view),
+                    ...(ruleEdge ? { rule: ruleEdge.rule } : {}),
+                    viewPrivilege: grantEdge?.privilege,
+                    baseRlsEnabled: base.rlsEnabled,
+                    rlsBypassed,
+                    proof: cell.proof
+                }
+            });
+        }
+    }
+    return out;
+}