@safegres/test 0.0.2 → 1.30.7

package/corpus/cases/24-anon-set-role-escalation/schema.sql

@@ -0,0 +1,30 @@
+DROP SCHEMA IF EXISTS c_anon_set_role_escalation CASCADE;
+CREATE SCHEMA c_anon_set_role_escalation;
+
+-- A privileged role the anonymous role is not meant to *be*, but can *become*.
+DO $$ BEGIN
+  CREATE ROLE c_priv_role NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_anon_set_role_escalation TO corpus_anon, corpus_user, c_priv_role;
+
+-- The flaw: corpus_anon inherits *nothing* from c_priv_role (INHERIT FALSE), so
+-- every passive-grant check sees an anonymous role that holds no privileges on
+-- the table below. But SET TRUE lets it `SET ROLE c_priv_role` on demand and
+-- execute with that role's grants — an escalation invisible to A2/R1/L5.
+GRANT c_priv_role TO corpus_anon WITH INHERIT FALSE, SET TRUE;
+
+CREATE TABLE c_anon_set_role_escalation.secrets (
+  id bigserial PRIMARY KEY,
+  is_public boolean NOT NULL DEFAULT false,
+  detail text
+);
+ALTER TABLE c_anon_set_role_escalation.secrets ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_anon_set_role_escalation.secrets FORCE ROW LEVEL SECURITY;
+
+-- A properly scoped table for the role that owns the access: c_priv_role can
+-- read, corpus_anon cannot — unless it assumes c_priv_role.
+CREATE POLICY secrets_read ON c_anon_set_role_escalation.secrets
+  FOR SELECT TO c_priv_role USING (is_public);
+GRANT SELECT ON c_anon_set_role_escalation.secrets TO c_priv_role;

package/corpus/cases/25-definer-view-bypass/case.json

@@ -0,0 +1,31 @@
+{
+  "title": "Anonymous role reads a locked table through a DEFINER view",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_definer_view_bypass"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L8",
+      "relation": "c_definer_view_bypass.orders",
+      "note": "the view is not security_invoker, so corpus_anon's SELECT on it reads `orders` as c_definer_view_owner — a grant no ACL row on `orders` gives it"
+    }
+  ],
+  "forbid": [
+    "A2",
+    "R1",
+    "L4"
+  ],
+  "worstSeverity": "info",
+  "fix": "Recreate c_definer_view_bypass.order_totals WITH (security_invoker = true) so the caller's own grants and policies apply, or give it an owner whose reach matches what the view is meant to expose. Revoking corpus_anon's SELECT on the view is not the fix — that grant is what the API serves.",
+  "id": "25-definer-view-bypass"
+}

package/corpus/cases/25-definer-view-bypass/schema.sql

@@ -0,0 +1,36 @@
+DROP SCHEMA IF EXISTS c_definer_view_bypass CASCADE;
+CREATE SCHEMA c_definer_view_bypass;
+
+-- The role the view executes as. It owns the base table, so its reach is
+-- everything the table's policies were written to constrain.
+DO $$ BEGIN
+  CREATE ROLE c_definer_view_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_definer_view_bypass TO corpus_anon, corpus_user, c_definer_view_owner;
+
+CREATE TABLE c_definer_view_bypass.orders (
+  id bigserial PRIMARY KEY,
+  customer text NOT NULL,
+  total numeric NOT NULL
+);
+ALTER TABLE c_definer_view_bypass.orders OWNER TO c_definer_view_owner;
+ALTER TABLE c_definer_view_bypass.orders ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_definer_view_bypass.orders FORCE ROW LEVEL SECURITY;
+
+-- The table is correctly locked down: only the signed-in role can read it, and
+-- only its own rows. corpus_anon holds no grant on it at all.
+CREATE POLICY orders_own_rows ON c_definer_view_bypass.orders
+  FOR SELECT TO corpus_user USING (customer = (SELECT current_setting('app.customer', true)));
+CREATE INDEX orders_customer_idx ON c_definer_view_bypass.orders (customer);
+GRANT SELECT ON c_definer_view_bypass.orders TO corpus_user;
+
+-- The flaw: the view is not `security_invoker`, so it executes as its owner —
+-- who owns the base table. corpus_anon holds nothing but SELECT on the view,
+-- and reads every order through it. No ACL row on `orders` names corpus_anon,
+-- so every catalog-only check sees a table the anonymous role cannot reach.
+CREATE VIEW c_definer_view_bypass.order_totals AS
+  SELECT id, customer, total FROM c_definer_view_bypass.orders;
+ALTER VIEW c_definer_view_bypass.order_totals OWNER TO c_definer_view_owner;
+GRANT SELECT ON c_definer_view_bypass.order_totals TO corpus_anon;

package/corpus/cases/26-invoker-view-no-bypass/case.json

@@ -0,0 +1,31 @@
+{
+  "title": "A security_invoker view over the same shape is not a bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_invoker_view_no_bypass"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A3",
+      "relation": "c_invoker_view_no_bypass.orders",
+      "note": "the only real finding left: RLS is not FORCEd, so the table owner still reads every row"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L5",
+    "A2"
+  ],
+  "worstSeverity": "low",
+  "fix": "ALTER TABLE c_invoker_view_no_bypass.orders FORCE ROW LEVEL SECURITY. The view needs no fix — `security_invoker` is what the definer-view bypass (case 25) is fixed *into*, and a rule that reported L8 here would be flagging a correct schema.",
+  "id": "26-invoker-view-no-bypass"
+}

package/corpus/cases/26-invoker-view-no-bypass/schema.sql

@@ -0,0 +1,44 @@
+DROP SCHEMA IF EXISTS c_invoker_view_no_bypass CASCADE;
+CREATE SCHEMA c_invoker_view_no_bypass;
+
+-- The same shape as 25-definer-view-bypass, with the one difference that
+-- decides it: the view is `security_invoker`, so it executes as the caller.
+DO $$ BEGIN
+  CREATE ROLE c_invoker_view_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_invoker_view_no_bypass TO corpus_anon, corpus_user, c_invoker_view_owner;
+
+CREATE TABLE c_invoker_view_no_bypass.orders (
+  id bigserial PRIMARY KEY,
+  customer text NOT NULL,
+  total numeric NOT NULL
+);
+ALTER TABLE c_invoker_view_no_bypass.orders OWNER TO c_invoker_view_owner;
+ALTER TABLE c_invoker_view_no_bypass.orders ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY orders_own_rows ON c_invoker_view_no_bypass.orders
+  FOR SELECT TO corpus_user USING (customer = (SELECT current_setting('app.customer', true)));
+CREATE INDEX orders_customer_idx ON c_invoker_view_no_bypass.orders (customer);
+GRANT SELECT ON c_invoker_view_no_bypass.orders TO corpus_user;
+
+-- corpus_anon can SELECT the view and nothing else, exactly as in case 25 —
+-- but `security_invoker` means Postgres checks *corpus_anon's* privileges on
+-- `orders`, which are none, so the read is denied. There is no bypass here and
+-- a rule that reported one would be recommending a change to a correct schema.
+CREATE VIEW c_invoker_view_no_bypass.order_totals
+  WITH (security_invoker = true) AS
+  SELECT id, customer, total FROM c_invoker_view_no_bypass.orders;
+ALTER VIEW c_invoker_view_no_bypass.order_totals OWNER TO c_invoker_view_owner;
+GRANT SELECT ON c_invoker_view_no_bypass.order_totals TO corpus_anon;
+
+-- `security_invoker` is a boolean reloption, and Postgres stores whichever
+-- spelling was written: `on` here is exactly as invoker as `true` above. A
+-- reader that string-matches 'true' calls this view a definer view and tells
+-- the author to fix a schema that is already correct.
+CREATE VIEW c_invoker_view_no_bypass.order_totals_on
+  WITH (security_invoker = on) AS
+  SELECT id, customer, total FROM c_invoker_view_no_bypass.orders;
+ALTER VIEW c_invoker_view_no_bypass.order_totals_on OWNER TO c_invoker_view_owner;
+GRANT SELECT ON c_invoker_view_no_bypass.order_totals_on TO corpus_anon;

package/corpus/cases/27-definer-view-write/case.json

@@ -0,0 +1,36 @@
+{
+  "title": "Anonymous role writes a locked table through an auto-updatable DEFINER view",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_definer_view_write"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L9",
+      "relation": "c_definer_view_write.submissions",
+      "note": "the view is auto-updatable and not security_invoker, so corpus_anon's INSERT on it inserts into `submissions` as c_view_write_owner — a write no ACL row on `submissions` gives it"
+    },
+    {
+      "code": "A3",
+      "relation": "c_definer_view_write.submissions",
+      "note": "RLS is not FORCEd, which is exactly why the owner's rewritten insert is not filtered by the table's own policy"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L10",
+    "L4"
+  ],
+  "worstSeverity": "low",
+  "fix": "Recreate c_definer_view_write.submission_inbox WITH (security_invoker = true) so the insert is checked against the caller, or give the view an owner whose reach matches what it is meant to expose. Revoking corpus_anon's INSERT on the view is not the fix — that grant is what the API serves.",
+  "id": "27-definer-view-write"
+}

package/corpus/cases/27-definer-view-write/schema.sql

@@ -0,0 +1,40 @@
+DROP SCHEMA IF EXISTS c_definer_view_write CASCADE;
+CREATE SCHEMA c_definer_view_write;
+
+-- The role the view executes as, and the owner of the table behind it.
+DO $$ BEGIN
+  CREATE ROLE c_view_write_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_definer_view_write TO corpus_anon, corpus_user, c_view_write_owner;
+
+CREATE TABLE c_definer_view_write.submissions (
+  id bigserial PRIMARY KEY,
+  author text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_definer_view_write.submissions OWNER TO c_view_write_owner;
+ALTER TABLE c_definer_view_write.submissions ENABLE ROW LEVEL SECURITY;
+
+-- Signed-in users write their own rows and read them back. corpus_anon holds
+-- no grant on the table at all.
+CREATE POLICY submissions_own_rows ON c_definer_view_write.submissions
+  FOR ALL TO corpus_user
+  USING (author = (SELECT current_setting('app.author', true)))
+  WITH CHECK (author = (SELECT current_setting('app.author', true)));
+CREATE INDEX submissions_author_idx ON c_definer_view_write.submissions (author);
+GRANT SELECT, INSERT ON c_definer_view_write.submissions TO corpus_user;
+GRANT USAGE ON SEQUENCE c_definer_view_write.submissions_id_seq TO corpus_user;
+
+-- The flaw: a simple view over one table is *auto-updatable*, so Postgres
+-- rewrites an INSERT on the view into an INSERT on `submissions` — and because
+-- the view is not `security_invoker`, that insert is permission-checked
+-- against the view's owner, who owns the table. corpus_anon holds nothing but
+-- INSERT on the view, and writes rows no policy of `submissions` would have
+-- admitted from it. Nothing in the body says so: the write path is
+-- `pg_relation_is_updatable`, not `pg_get_viewdef`.
+CREATE VIEW c_definer_view_write.submission_inbox AS
+  SELECT id, author, body FROM c_definer_view_write.submissions;
+ALTER VIEW c_definer_view_write.submission_inbox OWNER TO c_view_write_owner;
+GRANT INSERT ON c_definer_view_write.submission_inbox TO corpus_anon;

package/corpus/cases/28-invoker-view-no-write/case.json

@@ -0,0 +1,31 @@
+{
+  "title": "A security_invoker view over the same auto-updatable shape is not a write bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_invoker_view_no_write"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A3",
+      "relation": "c_invoker_view_no_write.submissions",
+      "note": "the only real finding left: RLS is not FORCEd, so the table owner still sees and writes every row"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L9",
+    "L10"
+  ],
+  "worstSeverity": "low",
+  "fix": "ALTER TABLE c_invoker_view_no_write.submissions FORCE ROW LEVEL SECURITY. The view needs no fix — `security_invoker` is what the definer-view write path (case 27) is fixed *into*.",
+  "id": "28-invoker-view-no-write"
+}

package/corpus/cases/28-invoker-view-no-write/schema.sql

@@ -0,0 +1,37 @@
+DROP SCHEMA IF EXISTS c_invoker_view_no_write CASCADE;
+CREATE SCHEMA c_invoker_view_no_write;
+
+DO $$ BEGIN
+  CREATE ROLE c_invoker_write_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_invoker_view_no_write
+  TO corpus_anon, corpus_user, c_invoker_write_owner;
+
+CREATE TABLE c_invoker_view_no_write.submissions (
+  id bigserial PRIMARY KEY,
+  author text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_invoker_view_no_write.submissions OWNER TO c_invoker_write_owner;
+ALTER TABLE c_invoker_view_no_write.submissions ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY submissions_own_rows ON c_invoker_view_no_write.submissions
+  FOR ALL TO corpus_user
+  USING (author = (SELECT current_setting('app.author', true)))
+  WITH CHECK (author = (SELECT current_setting('app.author', true)));
+CREATE INDEX submissions_author_idx ON c_invoker_view_no_write.submissions (author);
+GRANT SELECT, INSERT ON c_invoker_view_no_write.submissions TO corpus_user;
+GRANT USAGE ON SEQUENCE c_invoker_view_no_write.submissions_id_seq TO corpus_user;
+
+-- The same auto-updatable shape as case 27, with the one difference that
+-- matters: `security_invoker` sends the rewritten insert through the caller's
+-- own privileges, so corpus_anon's INSERT on the view is denied on
+-- `submissions` exactly as a direct insert would be. There is no write edge
+-- here, and a rule that reported one would be flagging a correct schema.
+CREATE VIEW c_invoker_view_no_write.submission_inbox
+  WITH (security_invoker = true) AS
+  SELECT id, author, body FROM c_invoker_view_no_write.submissions;
+ALTER VIEW c_invoker_view_no_write.submission_inbox OWNER TO c_invoker_write_owner;
+GRANT INSERT ON c_invoker_view_no_write.submission_inbox TO corpus_anon;

package/corpus/cases/29-rewrite-rule-bypass/case.json

@@ -0,0 +1,36 @@
+{
+  "title": "Anonymous role writes an audit table through a rewrite rule on a view",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_rewrite_rule_bypass"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L10",
+      "relation": "c_rewrite_rule_bypass.audit_log",
+      "note": "the rule's action runs as the view owner c_rule_owner, so corpus_anon's INSERT on the view appends to `audit_log` — and `security_invoker` on the view does not govern it"
+    },
+    {
+      "code": "A1",
+      "relation": "c_rewrite_rule_bypass.audit_log",
+      "note": "the audit table has RLS on and no policies, which is the correct posture for a table only its owner writes — and exactly why the rule's owner-privileged write is worth naming"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L9",
+    "L4"
+  ],
+  "worstSeverity": "low",
+  "fix": "Move the audit write into a function corpus_anon must be granted EXECUTE on, or give c_rewrite_rule_bypass.message_inbox an owner whose reach matches what the rule is meant to do. Revoking corpus_anon's INSERT on the view is not the fix — that grant is what the API serves.",
+  "id": "29-rewrite-rule-bypass"
+}

package/corpus/cases/29-rewrite-rule-bypass/schema.sql

@@ -0,0 +1,52 @@
+DROP SCHEMA IF EXISTS c_rewrite_rule_bypass CASCADE;
+CREATE SCHEMA c_rewrite_rule_bypass;
+
+DO $$ BEGIN
+  CREATE ROLE c_rule_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_rewrite_rule_bypass TO corpus_anon, corpus_user, c_rule_owner;
+
+CREATE TABLE c_rewrite_rule_bypass.messages (
+  id bigserial PRIMARY KEY,
+  author text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_rewrite_rule_bypass.messages OWNER TO c_rule_owner;
+ALTER TABLE c_rewrite_rule_bypass.messages ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_rewrite_rule_bypass.messages FORCE ROW LEVEL SECURITY;
+
+CREATE POLICY messages_own_rows ON c_rewrite_rule_bypass.messages
+  FOR ALL TO corpus_user
+  USING (author = (SELECT current_setting('app.author', true)))
+  WITH CHECK (author = (SELECT current_setting('app.author', true)));
+CREATE INDEX messages_author_idx ON c_rewrite_rule_bypass.messages (author);
+GRANT SELECT, INSERT ON c_rewrite_rule_bypass.messages TO corpus_user;
+GRANT USAGE ON SEQUENCE c_rewrite_rule_bypass.messages_id_seq TO corpus_user;
+
+-- An append-only audit trail nobody but the owner is meant to write.
+CREATE TABLE c_rewrite_rule_bypass.audit_log (
+  id bigserial PRIMARY KEY,
+  note text NOT NULL
+);
+ALTER TABLE c_rewrite_rule_bypass.audit_log OWNER TO c_rule_owner;
+ALTER TABLE c_rewrite_rule_bypass.audit_log ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_rewrite_rule_bypass.audit_log FORCE ROW LEVEL SECURITY;
+
+-- The flaw, and note what it survives: the view *is* `security_invoker`, so
+-- its own base relation is read and written as the caller. That setting does
+-- not reach the rule. A rewrite rule's actions are permission-checked against
+-- the owner of the relation the rule is on, so corpus_anon's INSERT on the
+-- view writes `audit_log` as c_rule_owner. `pg_get_viewdef` never names
+-- `audit_log`: no reading of the view's definition can find this edge.
+CREATE VIEW c_rewrite_rule_bypass.message_inbox
+  WITH (security_invoker = true) AS
+  SELECT id, author, body FROM c_rewrite_rule_bypass.messages;
+ALTER VIEW c_rewrite_rule_bypass.message_inbox OWNER TO c_rule_owner;
+
+CREATE RULE message_inbox_insert AS
+  ON INSERT TO c_rewrite_rule_bypass.message_inbox
+  DO INSTEAD INSERT INTO c_rewrite_rule_bypass.audit_log (note) VALUES (new.body);
+
+GRANT INSERT ON c_rewrite_rule_bypass.message_inbox TO corpus_anon;

package/corpus/cases/30-instead-nothing-rule/case.json

@@ -0,0 +1,31 @@
+{
+  "title": "A DO INSTEAD NOTHING rule reaches nothing and is not a write bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_instead_nothing_rule"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A3",
+      "relation": "c_instead_nothing_rule.messages",
+      "note": "the only real finding: RLS is not FORCEd, so the table owner still reads every row — the rules themselves confer nothing"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L9",
+    "L10"
+  ],
+  "worstSeverity": "low",
+  "fix": "ALTER TABLE c_instead_nothing_rule.messages FORCE ROW LEVEL SECURITY. The view and its rules need no fix — `DO INSTEAD NOTHING` is what a read-only view is *built* from, and this case exists to pin that the write rules stay silent on it.",
+  "id": "30-instead-nothing-rule"
+}

package/corpus/cases/30-instead-nothing-rule/schema.sql

@@ -0,0 +1,44 @@
+DROP SCHEMA IF EXISTS c_instead_nothing_rule CASCADE;
+CREATE SCHEMA c_instead_nothing_rule;
+
+DO $$ BEGIN
+  CREATE ROLE c_readonly_view_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_instead_nothing_rule
+  TO corpus_anon, corpus_user, c_readonly_view_owner;
+
+CREATE TABLE c_instead_nothing_rule.messages (
+  id bigserial PRIMARY KEY,
+  author text NOT NULL,
+  body text NOT NULL
+);
+ALTER TABLE c_instead_nothing_rule.messages OWNER TO c_readonly_view_owner;
+ALTER TABLE c_instead_nothing_rule.messages ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY messages_own_rows ON c_instead_nothing_rule.messages
+  FOR ALL TO corpus_user
+  USING (author = (SELECT current_setting('app.author', true)))
+  WITH CHECK (author = (SELECT current_setting('app.author', true)));
+CREATE INDEX messages_author_idx ON c_instead_nothing_rule.messages (author);
+GRANT SELECT, INSERT ON c_instead_nothing_rule.messages TO corpus_user;
+GRANT USAGE ON SEQUENCE c_instead_nothing_rule.messages_id_seq TO corpus_user;
+
+-- The commonest rule in the wild, and a correct one: `DO INSTEAD NOTHING`
+-- makes the view read-only by swallowing the write. It reaches no relation at
+-- all, so it confers nothing, and a rule that reported a write edge here would
+-- be flagging the very construct that closes the write path.
+CREATE VIEW c_instead_nothing_rule.message_feed
+  WITH (security_invoker = true) AS
+  SELECT id, author, body FROM c_instead_nothing_rule.messages;
+ALTER VIEW c_instead_nothing_rule.message_feed OWNER TO c_readonly_view_owner;
+
+CREATE RULE message_feed_no_insert AS
+  ON INSERT TO c_instead_nothing_rule.message_feed DO INSTEAD NOTHING;
+CREATE RULE message_feed_no_update AS
+  ON UPDATE TO c_instead_nothing_rule.message_feed DO INSTEAD NOTHING;
+CREATE RULE message_feed_no_delete AS
+  ON DELETE TO c_instead_nothing_rule.message_feed DO INSTEAD NOTHING;
+
+GRANT SELECT, INSERT ON c_instead_nothing_rule.message_feed TO corpus_anon;

package/corpus/cases/31-matview-snapshot/case.json

@@ -0,0 +1,32 @@
+{
+  "title": "Anonymous role reads an RLS-protected table's rows out of a materialized view",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_matview_snapshot"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L11",
+      "relation": "c_matview_snapshot.readings",
+      "note": "the matview stores rows computed as c_matview_owner, so corpus_anon reads every tenant's readings without holding a grant on the table and without its policies ever running"
+    }
+  ],
+  "forbid": [
+    "L8",
+    "L9",
+    "L10",
+    "L12"
+  ],
+  "worstSeverity": "info",
+  "fix": "Serve the rollup from a `security_invoker` view, or materialize only the columns and rows that are safe to hand out unconditionally and keep the full snapshot in a schema the API does not expose. A materialized view can carry neither RLS policies nor `security_invoker`, so there is no option on the matview itself that reinstates the filter — and revoking corpus_anon's SELECT on it is not the fix, that grant is what the API serves.",
+  "id": "31-matview-snapshot"
+}

package/corpus/cases/31-matview-snapshot/schema.sql

@@ -0,0 +1,36 @@
+DROP SCHEMA IF EXISTS c_matview_snapshot CASCADE;
+CREATE SCHEMA c_matview_snapshot;
+
+-- The role that owns the table and runs REFRESH.
+DO $$ BEGIN
+  CREATE ROLE c_matview_owner NOLOGIN;
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+GRANT USAGE ON SCHEMA c_matview_snapshot TO corpus_anon, corpus_user, c_matview_owner;
+
+CREATE TABLE c_matview_snapshot.readings (
+  id bigserial PRIMARY KEY,
+  tenant text NOT NULL,
+  value numeric NOT NULL
+);
+ALTER TABLE c_matview_snapshot.readings OWNER TO c_matview_owner;
+ALTER TABLE c_matview_snapshot.readings ENABLE ROW LEVEL SECURITY;
+ALTER TABLE c_matview_snapshot.readings FORCE ROW LEVEL SECURITY;
+
+-- Signed-in users see only their own tenant's rows.
+CREATE POLICY readings_own_tenant ON c_matview_snapshot.readings
+  FOR SELECT TO corpus_user
+  USING (tenant = (SELECT current_setting('app.tenant', true)));
+CREATE INDEX readings_tenant_idx ON c_matview_snapshot.readings (tenant);
+GRANT SELECT ON c_matview_snapshot.readings TO corpus_user;
+
+-- The flaw: a materialized view is a stored copy. Its rows were computed once,
+-- as c_matview_owner, and reading it never consults `readings` — so neither
+-- the table's ACL nor its policies apply, and the matview can carry neither
+-- policies nor `security_invoker` of its own. corpus_anon holds nothing on
+-- `readings` and reads every tenant's rows out of the snapshot.
+CREATE MATERIALIZED VIEW c_matview_snapshot.readings_rollup AS
+  SELECT id, tenant, value FROM c_matview_snapshot.readings;
+ALTER MATERIALIZED VIEW c_matview_snapshot.readings_rollup OWNER TO c_matview_owner;
+GRANT SELECT ON c_matview_snapshot.readings_rollup TO corpus_anon, corpus_user;

package/corpus/cases/32-matview-no-rls-no-bypass/case.json

@@ -0,0 +1,30 @@
+{
+  "title": "A materialized view over a table the role can already read is a cache, not a bypass",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_matview_no_bypass"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "A2",
+      "relation": "c_matview_no_bypass.regions",
+      "note": "the only real finding left: the table is granted without RLS, which is the intent here — it is public reference data"
+    }
+  ],
+  "forbid": [
+    "L11",
+    "L12"
+  ],
+  "worstSeverity": "high",
+  "fix": "Nothing on the matview. The snapshot shows corpus_anon exactly what `regions` would, and no policy was skipped because there is none — this case exists to pin that L11 stays silent when materialization changes nothing about reach.",
+  "id": "32-matview-no-rls-no-bypass"
+}

package/corpus/cases/32-matview-no-rls-no-bypass/schema.sql

@@ -0,0 +1,18 @@
+DROP SCHEMA IF EXISTS c_matview_no_bypass CASCADE;
+CREATE SCHEMA c_matview_no_bypass;
+
+GRANT USAGE ON SCHEMA c_matview_no_bypass TO corpus_anon, corpus_user;
+
+-- Reference data: public by intent, no RLS, readable directly.
+CREATE TABLE c_matview_no_bypass.regions (
+  code text PRIMARY KEY,
+  label text NOT NULL
+);
+GRANT SELECT ON c_matview_no_bypass.regions TO corpus_anon, corpus_user;
+
+-- A matview over it is a cache, not a bypass: the snapshot shows corpus_anon
+-- nothing it could not select from `regions` itself, and there are no policies
+-- for the stored rows to have skipped. L11 must stay silent.
+CREATE MATERIALIZED VIEW c_matview_no_bypass.regions_cached AS
+  SELECT code, label FROM c_matview_no_bypass.regions;
+GRANT SELECT ON c_matview_no_bypass.regions_cached TO corpus_anon, corpus_user;

package/corpus/cases/33-leaky-filter-view/case.json

@@ -0,0 +1,36 @@
+{
+  "title": "A view's WHERE is the only boundary an anonymous role faces, and it is not a security barrier",
+  "dimension": "security",
+  "exposure": {
+    "schemas": [
+      "c_leaky_filter_view"
+    ],
+    "roles": [
+      "corpus_anon",
+      "corpus_user"
+    ],
+    "anonRoles": [
+      "corpus_anon"
+    ]
+  },
+  "expect": [
+    {
+      "code": "L12",
+      "relation": "c_leaky_filter_view.documents",
+      "note": "corpus_anon reaches `documents` only through the view, so the view's `visibility = 'public'` is a security boundary — and without `security_barrier` a caller-supplied leaky qual is evaluated against the private rows too"
+    },
+    {
+      "code": "L8",
+      "relation": "c_leaky_filter_view.documents",
+      "note": "the same view also executes as its owner, which is what puts corpus_anon in reach of the table at all"
+    }
+  ],
+  "forbid": [
+    "L9",
+    "L10",
+    "L11"
+  ],
+  "worstSeverity": "info",
+  "fix": "Recreate c_leaky_filter_view.public_documents WITH (security_barrier = true) so the planner cannot evaluate a caller's qual below the view's own. Where the filter is per-caller rather than a constant, an RLS policy on `documents` is stronger still: policy quals already get barrier treatment. Do not revoke corpus_anon's SELECT on the view.",
+  "id": "33-leaky-filter-view"
+}