@rebasepro/rls-check 0.17.3 → 0.18.0

package/README.md

@@ -3,9 +3,17 @@
 Audit Row-Level Security on any PostgreSQL database. One command, no configuration, no account, nothing to install.
 
 ```sh
-npx @rebasepro/rls-check "postgresql://user:password@host:5432/database"
+npx @rebasepro/rls-check
 ```
 
+ESM-only: `"type": "module"` with no CommonJS build. It is a command, so that
+matters only if you import it — `require()` of it resolves on Node 22.12+,
+which supports `require(esm)`.
+
+Run it in your project directory and it finds the database itself: `DATABASE_URL`, then `POSTGRES_URL`, then a `.env` beside you. Point it somewhere else with `DATABASE_URL="postgresql://user:password@host:5432/database" npx @rebasepro/rls-check`.
+
+It also takes the connection string as an argument, but prefer not to: npm echoes the command line before the program starts and your shell records it, so the password lands in two places `rls-check` cannot redact. Writing `$DATABASE_URL` there does not help — the shell expands it before npm sees it.
+
 It works against Supabase, Neon, RDS, Cloud SQL, Postgres in a container on your laptop, or anything else that speaks the wire protocol. It knows nothing about your framework and asks nothing of your codebase.
 
 **It is read-only.** It issues `SELECT`s against the system catalogs — `pg_class`, `pg_policies`, `pg_proc`, `information_schema` — and nothing else. It writes nothing, changes no setting, and sends nothing anywhere. There is no telemetry, no upload, and no network access beyond the connection you give it.
@@ -30,133 +38,113 @@ The failures that make a Postgres database leak in practice, rather than the one
 A scan of a Supabase project, `--no-color`:
 
 ```
-rls-check 0.10.0  ·  read-only Row-Level Security audit
-────────────────────────────────────────────────────────────────────────────
+rls-check 0.17.3  ·  read-only Row-Level Security audit
+────────────────────────────────────────────────────────────────────────────────────────
 
 Database  db.hjklqwertyuiop.supabase.co:5432/postgres
 Server    PostgreSQL 15.8 on aarch64-unknown-linux-gnu
 Platform  Supabase
-Scanned   1 schema · 23 tables · 31 policies · 14 checks
+Exposed   PUBLIC, anon, authenticated (add yours with --role)
+Scanned   1 schema · 3 tables · 2 policies · 15 checks
 
 Note  This scan connected as a role that row-level security cannot constrain — a
-      superuser, a table owner, or a role with BYPASSRLS. That is why it can read
-      the true catalog, and it is also why nothing below describes what this
-      connection experiences. The findings are about what OTHER roles get.
+      superuser, a table owner, or a role with BYPASSRLS. That is why it can read the
+      true catalog, and it is also why nothing below describes what this connection
+      experiences. The findings are about what OTHER roles get.
 
-CRITICAL  ·  2 findings
-────────────────────────────────────────────────────────────────────────────
+CRITICAL  ·  3 findings
+────────────────────────────────────────────────────────────────────────────────────────
 
-  [critical] rls-disabled  public.profiles
-      public.profiles is exposed to anon without row-level security
+  [critical] policy-always-true  public.contact_messages · policy "anyone can write"
+      Policy "anyone can write" on public.contact_messages is WITH CHECK (true) for anon
 
-      Row-level security is disabled on this table, and anon holds SELECT, INSERT,
-      UPDATE and DELETE on it. With RLS off, policies are not consulted at all — a
-      policy defined on this table would have no effect.
-      Impact  Anyone with the project's anon key, which ships in your client bundle,
-              can read and modify every row.
+      This permissive INSERT policy's WITH CHECK expression is a constant truth, so it
+      matches every row for anon. Permissive policies are ORed together, so this one
+      alone satisfies the table's row filter no matter how strict the others are.
+      Impact  If this table is reachable over an API as anon, a caller can act on every
+              row — the policy applies no scoping whatsoever.
       Fix
-          ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
-          ALTER TABLE public.profiles FORCE ROW LEVEL SECURITY;
+          -- Replace the constant with the scoping you intended, e.g.:
+          ALTER POLICY "anyone can write" ON "public"."contact_messages"
+              WITH CHECK (user_id = auth.uid());
+          -- or, if unconditional access really is intended, drop the policy and say so
+          -- with an explicit grant instead:
+          -- DROP POLICY "anyone can write" ON "public"."contact_messages";
+      Docs    https://rebase.pro/docs/rls-check#policy-always-true
 
-          -- Then add at least one policy, or the table denies everything:
-          CREATE POLICY profiles_select_own ON public.profiles
-              FOR SELECT TO authenticated USING (id = auth.uid());
+  [critical] rls-disabled  public.profiles
+      public.profiles has row-level security disabled and is granted to anon and
+      authenticated
+
+      Row-level security is not enabled on this table, so Postgres applies no per-row
+      filter at all — policies, if any exist, are never consulted. anon and
+      authenticated hold DELETE, INSERT, SELECT and UPDATE on it.
+      Impact  If this table is reachable over an API that connects as anon and
+              authenticated, a caller can read every row and delete, insert and update
+              any row, with no tenant or owner scoping.
+      Fix
+          ALTER TABLE "public"."profiles" ENABLE ROW LEVEL SECURITY;
+          -- Enabling RLS with no policies denies every row to everyone but the owner,
+          -- so add the policy you intend in the same migration, for example:
+          -- CREATE POLICY "profiles_owner_select" ON "public"."profiles"
+          --     FOR SELECT TO "anon" USING (user_id = auth.uid());
       Docs    https://rebase.pro/docs/rls-check#rls-disabled
 
   [critical] view-bypasses-rls  public.user_stats
-      public.user_stats reads past the row-level security on public.profiles
-
-      The view is granted to anon and does not set security_invoker, so it executes
-      with the privileges of its owner (postgres) rather than the caller's. The
-      policies on public.profiles never run.
-      Impact  An anon caller selecting from the view receives every row of
-              public.profiles, whatever its policies say.
+      View public.user_stats reads public.orders without security_invoker and is
+      readable by anon
+
+      The view is owned by postgres and `security_invoker` is not set, so its query
+      executes with postgres's privileges rather than the caller's. Row-level security
+      on public.orders is evaluated for postgres, not for the role that selected from
+      the view.
+      Impact  If this view is reachable over an API as anon, a caller reads rows from
+              public.orders that the policies on that table were written to withhold —
+              the view is an unfiltered path around them.
       Fix
-          ALTER VIEW public.user_stats SET (security_invoker = true);
+          ALTER VIEW "public"."user_stats" SET (security_invoker = true);
+          -- Callers then need their own SELECT privilege on public.orders, and the
+          -- policies there apply to them.
       Docs    https://rebase.pro/docs/rls-check#view-bypasses-rls
 
 HIGH  ·  1 finding
-────────────────────────────────────────────────────────────────────────────
+────────────────────────────────────────────────────────────────────────────────────────
 
   [high] anonymous-write-allowed  public.contact_messages · policy "anyone can write"
-      public.contact_messages accepts inserts from anon under policy "anyone can
+      public.contact_messages accepts unauthenticated insert via policy "anyone can
       write"
 
-      The policy is PERMISSIVE, applies to INSERT, names anon in its TO clause, and
-      its WITH CHECK expression is `true`, so every proposed row passes.
-      Impact  Anyone holding the anon key can insert unlimited rows. There is no
-              rate limit at the database layer.
+      Policy "anyone can write" is a permissive INSERT policy for anon, and its check
+      expression is a constant truth, so every row satisfies it. anon also holds INSERT
+      on the table, so both the privilege check and the row check pass for a request
+      that carries no credentials.
+      Impact  An unauthenticated caller reaching this database over an API can insert
+              rows in public.contact_messages at will — inserting records attributed to
+              other users, or modifying rows they do not own.
       Fix
-          ALTER POLICY "anyone can write" ON public.contact_messages
-              WITH CHECK (created_by = auth.uid() AND length(body) < 4000);
+          -- Scope the write to the caller, or take the privilege away entirely:
+          ALTER POLICY "anyone can write" ON "public"."contact_messages"
+              WITH CHECK (user_id = auth.uid());
+          -- and if anonymous writes are never intended:
+          REVOKE INSERT ON "public"."contact_messages" FROM "anon";
       Docs    https://rebase.pro/docs/rls-check#anonymous-write-allowed
 
-MEDIUM  ·  2 findings
-────────────────────────────────────────────────────────────────────────────
-
-  [medium] grant-to-public  public.feature_flags
-      public.feature_flags grants SELECT to PUBLIC
-
-      PUBLIC is every role in the cluster, including roles created after this grant.
-      The grant survives changes to anon and authenticated.
-      Impact  Any role that can connect can read this table, whether or not you
-              intended it to be reachable.
-      Fix
-          REVOKE SELECT ON public.feature_flags FROM PUBLIC;
-          GRANT SELECT ON public.feature_flags TO authenticated;
-      Docs    https://rebase.pro/docs/rls-check#grant-to-public
-
-  [medium] rls-enabled-not-forced  public.orders
-      public.orders does not force row-level security for its owner
-
-      RLS is enabled but not FORCEd, so the table's owner (postgres) is exempt from
-      its own policies. Any SECURITY DEFINER function owned by that role reads the
-      table unfiltered.
-      Impact  A trigger, a scheduled job, or an RPC running as the owner sees every
-              tenant's rows even though the policies say otherwise.
-      Fix
-          ALTER TABLE public.orders FORCE ROW LEVEL SECURITY;
-      Docs    https://rebase.pro/docs/rls-check#rls-enabled-not-forced
-
-WORTH CHECKING
-  These are heuristics, not proofs. They match a shape that is usually a mistake,
-  but each one may be deliberate in your schema — read them and decide. They are
-  listed separately so nothing above needs a second opinion.
-
-  [high] junction-table-unprotected  public.project_members
-      public.project_members looks like a join table between two protected tables
-      and has no RLS
-
-      The table is two foreign keys and a primary key over both, pointing at
-      public.projects and public.profiles — both of which have row-level security.
-      This one does not.
-      Impact  If this table is exposed over an API, the full membership graph is
-              readable: who belongs to which project, for every project.
-      Fix
-          ALTER TABLE public.project_members ENABLE ROW LEVEL SECURITY;
-          ALTER TABLE public.project_members FORCE ROW LEVEL SECURITY;
-
-          CREATE POLICY project_members_follows_project ON public.project_members
-              FOR SELECT TO authenticated USING (EXISTS (
-                  SELECT 1 FROM public.projects p
-                  WHERE p.id = project_members.project_id AND p.owner_id = auth.uid()
-              ));
-      Docs    https://rebase.pro/docs/rls-check#junction-table-unprotected
-
-────────────────────────────────────────────────────────────────────────────
+────────────────────────────────────────────────────────────────────────────────────────
 Summary
 
-  critical 2   high 2   medium 2   low 1   info 0
-  5 confirmed · 2 worth checking · 14 checks run against 23 tables in 1 schema
-  3 of 23 tables have row-level security disabled
+  critical 3   high 1   medium 0   low 0   info 0
+  4 confirmed · 0 worth checking · 15 checks run against 3 tables in 1 schema
+  1 of 3 tables have row-level security disabled
 
   Exit code 1 — at least one finding is "high" or worse (--fail-on high).
-  Scanned 2026-07-26T09:14:02.881Z · read-only, and nothing left this machine.
+  Scanned 2026-09-05T09:14:02.881Z · read-only, and nothing left this machine.
 
 rls-check is free and maintained by the team behind Rebase — https://rebase.pro
 ```
 
-Heuristic findings are always kept in their own section, after the confident ones. Mixing "this table is public" with "this might be a join table" is how a scanner teaches people to ignore it.
+That run found nothing heuristic. When it does, the heuristic findings go in a `WORTH CHECKING` section of their own, after the confident ones — mixing "this table is public" with "this might be a join table" is how a scanner teaches people to ignore it.
+
+The `Exposed` line is worth reading before the findings: every check reports a table only when one of those roles can reach it, so if the role your application connects as is not listed, name it with `--role` and run again.
 
 ## The checks
 
@@ -168,6 +156,7 @@ Run `npx @rebasepro/rls-check --list-checks` for the catalog on your installed v
 | `policy-always-true` | critical | certain | A permissive policy whose `USING` or `WITH CHECK` expression is always true. Downgraded to medium, and to heuristic, when the policy sits behind an authentication gate. |
 | `view-bypasses-rls` | critical | certain | A view granted to an untrusted role that selects from an RLS-protected table and runs with its owner's privileges. Heuristic on servers before PG15, where `security_invoker` does not exist. |
 | `policy-anonymous-tautology` | varies | heuristic | An `auth.uid() IS NOT NULL`-shaped policy: it separates signed-in from signed-out callers and scopes no rows. Critical on Supabase-shaped databases, lower elsewhere. |
+| `policy-authenticated-tautology` | high | heuristic | The corrected form of the above — `auth.uid() IS NOT NULL AND auth.uid() <> 'anonymous'` — which excludes signed-out callers and still scopes no rows. Every account reads every row; with open registration that is everybody. |
 | `anonymous-write-allowed` | high | certain | A permissive INSERT/UPDATE/DELETE policy reachable without authentication whose check expression accepts any row, backed by a matching grant. |
 | `matview-bypasses-rls` | high | certain | A materialized view granted to an untrusted role whose defining query reads an RLS-protected table. Materialized views have no `security_invoker`. |
 | `unqualified-column-in-subquery` | high | heuristic | A bare column name in an `EXISTS`/`IN` subquery that exists on both the inner relation and the policy's own table, so Postgres binds it to the inner one. |
@@ -184,12 +173,16 @@ Ids are stable. They go into `--skip` lists and CI baselines, so a rename is tre
 ## Usage
 
 ```
+DATABASE_URL="postgresql://..." npx @rebasepro/rls-check [options]
 npx @rebasepro/rls-check [connection-string] [options]
 
   --json                 Machine-readable ScanResult on stdout, and nothing else.
+  --html <path>          Also write a self-contained HTML report to <path>. One file,
+                         no network requests, safe to attach to a ticket.
   --schema <name>        Restrict the scan to a schema. Repeatable or comma-separated.
   --role <name>          Treat this role as one an untrusted caller arrives as, in
                          addition to anon, authenticated, web_anon and rebase_user.
+                         A name that is not in pg_roles is an error, not a no-op.
                          Repeatable or comma-separated.
   --fail-on <severity>   Exit 1 at or above this severity: info, low, medium, high,
                          critical, or none to never fail. Default: high.
@@ -213,7 +206,9 @@ The connection string is taken from, in order:
 
 The connection string never appears in the output — not in the report, not in an error, not in a log line. Host, port and database name are shown; the user and password are replaced with `***`.
 
-If your password contains `@`, `:`, `/`, `?` or `#`, percent-encode it. An unencoded one makes the URL ambiguous, and `rls-check` refuses to guess rather than risk connecting somewhere unintended.
+If your password contains `/`, `?` or `#`, percent-encode it. Those three end the URL's authority section, so the split lands inside the credential — and rather than print fragments of a password, `rls-check` refuses the string and says so.
+
+`@` and `:` need no encoding here: the userinfo is split at the **last** `@` and the user at the **first** `:`, which is what `pg` does too, so `postgresql://user:pa@ss@host:5432/db` connects to `host` with the password `pa@ss`. Encoding them anyway is never wrong.
 
 ## Exit codes
 
@@ -253,49 +248,96 @@ To keep the machine-readable result as an artifact:
         run: npx --yes @rebasepro/rls-check --json > rls-report.json
 ```
 
+### On a Rebase database, change the rule, not the policy
+
+Every policy on a Rebase deployment is compiled from a collection's `securityRules`, and the runtime re-applies them on every boot — it drops each generated policy and creates it again from the config. SQL run against one of them survives exactly until the next restart, so `rls-check` recognises those policies (a `<table>_<operation>_<hash>` name, or a call to `rebase.uid()` / `rebase.roles()` in the expression) and prescribes the rule instead: edit the collection under `config/collections/`, or `defaultSecurityRules` in `config/collections/index.ts` when the collection declares none of its own, then redeploy. A policy you wrote by hand in a migration is untouched by this, and its fix is still the SQL.
+
+A stock Rebase scaffold reports three `policy-always-true` criticals on its first scan — `posts`, `authors` and `tags` inherit a `{ operation: "select", access: "public" }` rule — so decide whether to replace those rules or to `--skip policy-always-true` before you make this a gate.
+
 ## JSON output
 
 `--json` writes a single `ScanResult` object to stdout and nothing else. Errors still go to stderr.
 
 ```json
 {
-  "scannedAt": "2026-07-26T09:14:02.881Z",
-  "database": { "host": "db.hjklqwertyuiop.supabase.co", "name": "postgres" },
+  "scannedAt": "2026-09-05T09:14:02.881Z",
+  "database": {
+    "host": "db.hjklqwertyuiop.supabase.co",
+    "name": "postgres"
+  },
   "serverVersion": "PostgreSQL 15.8 on aarch64-unknown-linux-gnu",
   "platform": "supabase",
   "scannerIsPrivileged": true,
+  "exposedRoles": [
+    "PUBLIC",
+    "anon",
+    "authenticated"
+  ],
   "stats": {
     "schemas": 1,
-    "tables": 23,
-    "policies": 31,
-    "tablesWithoutRls": 3,
-    "checksRun": 14
+    "tables": 1,
+    "policies": 0,
+    "tablesWithoutRls": 1,
+    "checksRun": 15
   },
   "findings": [
     {
       "id": "rls-disabled",
       "severity": "critical",
-      "title": "public.profiles is exposed to anon without row-level security",
-      "target": { "schema": "public", "table": "profiles" },
-      "detail": "…",
-      "impact": "…",
-      "fix": "ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;",
-      "docs": "https://rebase.pro/docs/rls-check#rls-disabled",
-      "confidence": "certain"
+      "confidence": "certain",
+      "title": "public.profiles has row-level security disabled and is granted to anon",
+      "target": {
+        "schema": "public",
+        "table": "profiles"
+      },
+      "detail": "Row-level security is not enabled on this table, so Postgres applies no per-row filter at all — policies, if any exist, are never consulted. anon holds DELETE, INSERT, SELECT and UPDATE on it.",
+      "impact": "If this table is reachable over an API that connects as anon, a caller can read every row and delete, insert and update any row, with no tenant or owner scoping.",
+      "fix": "ALTER TABLE \"public\".\"profiles\" ENABLE ROW LEVEL SECURITY;\n-- Enabling RLS with no policies denies every row to everyone but the owner,\n-- so add the policy you intend in the same migration, for example:\n-- CREATE POLICY \"profiles_owner_select\" ON \"public\".\"profiles\"\n--     FOR SELECT TO \"anon\" USING (user_id = auth.uid());",
+      "docs": "https://rebase.pro/docs/rls-check#rls-disabled"
     }
-  ]
+  ],
+  "diagnostics": {
+    "tlsVerificationDisabled": false,
+    "excludedSchemas": [
+      {
+        "schema": "auth",
+        "reason": "platform"
+      },
+      {
+        "schema": "information_schema",
+        "reason": "system"
+      },
+      {
+        "schema": "pg_catalog",
+        "reason": "system"
+      },
+      {
+        "schema": "pg_toast",
+        "reason": "system"
+      },
+      {
+        "schema": "storage",
+        "reason": "platform"
+      }
+    ],
+    "degraded": [],
+    "unrecognizedGrantees": [],
+    "scanningAsExposedRole": null
+  }
 }
 ```
 
 Findings are sorted worst-first and then by schema, object and id, so two scans of an unchanged database produce an identical file.
 
+`exposedRoles` and `diagnostics` are part of the contract, not decoration. Every check reports a table only when one of the exposed roles can reach it, and `diagnostics.degraded` is how a consumer tells "nothing was wrong" from "the scan could not look" — `findings: []` without both is half an answer.
+
 ## What this tool does not do
 
 Being clear about this is the point of the tool. It is a **static audit of the catalog**, not a penetration test.
 
 - **It does not execute queries as other roles.** It never connects as `anon`, never sets a JWT claim, and never tries to read a row it should not be able to read. Everything it reports is inferred from what the catalogs say, not observed.
 - **It cannot prove a policy is correct.** Deciding whether `owner_id = auth.uid()` is the right rule for your application requires knowing your application. `rls-check` can only tell you that certain *shapes* are wrong — a policy that is always true, a view that runs as its owner, a table with RLS switched off.
-- **A clean report is not a security certification.** It means these fourteen checks found nothing. It does not mean your authorization model is sound, your API layer enforces what it should, or your data is safe.
+- **A clean report is not a security certification.** It means these fifteen checks found nothing. It does not mean your authorization model is sound, your API layer enforces what it should, or your data is safe.
 - **It recognises app roles by name, and yours may not be one of them.** Every check reports a table as exposed only when a role an untrusted caller can arrive as holds privileges on it. Out of the box that means `PUBLIC`, Supabase's `anon` and `authenticated`, PostgREST's `web_anon`, and Rebase's `rebase_user`. If your application connects as `app_user`, `api` or anything else, name it — `--role app_user` — or the checks have nothing to gate on. A scan that finds a write-holding role it cannot account for says so in a `Note` rather than printing a clean report.
 - **It does not model your API layer.** Whether a table is actually reachable depends on PostgREST, your server, or your gateway. Findings say "if this table is exposed over an API" when reachability depends on something outside the database — believe that qualifier.
 - **It does not see what your connection sees.** Almost every connection string handed to a tool like this belongs to a superuser or a table owner, which RLS cannot constrain. That is what lets it read the true catalog; it also means the findings describe what *other* roles get. The report says so, prominently, every time it applies.

package/dist/checks/policy-anonymous-tautology.d.ts

@@ -17,7 +17,55 @@ import type { Check } from "../types.js";
  *   - Anything else: it comes down to whether the stack coerces, which the
  *     database cannot tell us. `medium`, and say so out loud.
  *
- * A `<> 'anonymous'` guard alongside the null test is the corrected form and
- * clears the policy entirely.
+ * A guard that excludes the sentinel is the corrected form and clears the policy.
+ * A guard that excludes *something else* is the interesting case — see
+ * {@link matchTautology}.
  */
 export declare const policyAnonymousTautology: Check;
+export interface TautologyMatch {
+    /** How to name the caller-id expression in prose, e.g. `auth.uid()`. */
+    shape: string;
+    /** Literals the policy excludes that exclude nobody. Empty for a bare null test. */
+    decoyGuards: string[];
+    /**
+     * Whether the clause excludes an id a signed-out caller can actually arrive
+     * with — the *corrected* form of this shape.
+     *
+     * This is the fork between two findings. `false` is
+     * {@link policyAnonymousTautology}: the null test stands on its own, so
+     * signed-out callers satisfy it. `true` is `policy-authenticated-tautology`:
+     * signed-out callers really are excluded, and still no row is scoped, so
+     * every registered account reads every row — the shape that left a
+     * customer's `users` table readable by anyone who could sign up.
+     *
+     * Returning the distinction rather than treating the guarded form as a clean
+     * bill of health is the whole point: the previous version answered `null`
+     * here, which is why the policy that actually shipped passed silently.
+     */
+    guardsSentinel: boolean;
+}
+/**
+ * Recognise "the policy tests that a caller id exists, and nothing that narrows
+ * which rows" — and report which no-op guards it wears while doing so.
+ *
+ * Two rules keep this honest.
+ *
+ * **Every conjunct has to be accounted for.** `auth.uid() IS NOT NULL AND user_id
+ * = auth.uid()` contains the shape and is a perfectly scoped policy; a substring
+ * match would flag it, and flagging correct Supabase policies is the fastest way
+ * to get this tool deleted. So the expression is split on `AND`, each conjunct is
+ * classified, and a single conjunct this function does not recognise means it
+ * stays quiet. An `OR` anywhere means the same — the shape no longer describes
+ * what the policy admits.
+ *
+ * **A guard only clears if it excludes an id somebody can actually arrive with.**
+ * The version before this one bailed on the literal string `<> 'anonymous'`, which
+ * meant `<> 'anon'` fell past the bail and then failed to match the bare-null-test
+ * shape, so the function returned null and the check said nothing at all. That is
+ * not a near miss: it is the precise predicate that left a production `users`
+ * table — password hashes included — readable by the entire internet for three and
+ * a half weeks, and this tool was run against that database and reported clean.
+ * A guard naming the wrong literal is now the *loudest* case, not the silent one,
+ * because it is the one that survives code review.
+ */
+export declare function callerIdOnlyClause(clause: string | null | undefined): TautologyMatch | null;

package/dist/checks/policy-authenticated-tautology.d.ts

@@ -0,0 +1,27 @@
+import type { Check } from "../types.js";
+/**
+ * `auth.uid() IS NOT NULL AND auth.uid() <> 'anonymous'` — and nothing else.
+ *
+ * This is the *corrected* form of the anonymous tautology, and correcting that
+ * one is where people stop. It genuinely does exclude signed-out callers. What
+ * it does not do is scope any rows: what remains is "every registered account
+ * may read every row of this table", which is a different sentence from the one
+ * the person writing it usually means.
+ *
+ * It is the shape that leaked a customer's `users` table — every email address
+ * on the platform, and the columns beside them, readable by anyone who could
+ * sign up, which on a product with open registration is anyone at all. The
+ * scanner watched for the anonymous form and treated the sentinel guard as a
+ * clean bill of health, so the policy that actually shipped passed silently.
+ *
+ * `high`, not `critical`: it costs an account. On a table with open
+ * registration that is a formality, and the wording says so rather than
+ * pretending the distinction is comforting.
+ *
+ * Not folded into {@link policyAnonymousTautology}: check ids appear in
+ * `--skip`, in CI baselines and in people's runbooks, so two findings with
+ * different fixes and different severities have to be two ids. Someone who has
+ * decided their `countries` table really is world-readable should be able to
+ * silence that without also silencing "signed-out callers can read it".
+ */
+export declare const policyAuthenticatedTautology: Check;

package/dist/checks/util.d.ts

@@ -70,3 +70,31 @@ export declare const listAnd: (items: string[]) => string;
  * plenty of databases Rebase did not create, and that is the wider convention.
  */
 export declare function callerIdCall(snapshot: DbSnapshot): string;
+/**
+ * Is this policy one Rebase derives from a collection's `securityRules` and
+ * re-applies at every boot?
+ *
+ * It matters because the ordinary remediation — edit the policy in the database
+ * — is *silently undone* on such a policy: boot drops and recreates every
+ * generated policy from the collection config, so a fix applied with SQL
+ * survives exactly until the next restart. Prescribing it is worse than
+ * prescribing nothing, because the operator watches the finding disappear and
+ * files it as done.
+ *
+ * Gated on the platform as well as the shape: this scanner is pointed at plenty
+ * of databases Rebase did not create, and a hash-suffixed policy name on one of
+ * those is a coincidence, not a contract.
+ */
+export declare function isRebaseManagedPolicy(snapshot: DbSnapshot, policy: DbPolicy): boolean;
+/** Where the rule that produces a managed policy is documented. */
+export declare const SECURITY_RULES_DOCS = "https://rebase.pro/docs/collections/security-rules";
+/**
+ * The remediation for a Rebase-managed policy: change the rule it is compiled
+ * from. `intent` is one clause saying what to change the rule to, in the
+ * vocabulary of the check that found it.
+ *
+ * Deliberately contains no SQL. Every other fix in this tool is copy-pasteable
+ * because pasting it works; here it would not, and an example that is reverted
+ * on the next deploy teaches the wrong model of where access control lives.
+ */
+export declare function managedPolicyFix(policy: DbPolicy, intent: string): string;