Auditez la sécurité au niveau des lignes sur n'importe quel Postgres

$ npx @rebasepro/rls-check --role app_reader

rls-check 0.25.1  ·  read-only Row-Level Security audit
────────────────────────────────────────────────────────────────────────────────────────

Database  db.acme.internal:5432/production
Server    PostgreSQL 16.4
Platform  PostgreSQL (no platform markers)
Exposed   PUBLIC, app_reader (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.

CRITICAL  ·  3 findings
────────────────────────────────────────────────────────────────────────────────────────

  [critical] view-bypasses-rls  public.billing_overview
      View public.billing_overview reads public.ledger without security_invoker and is
      readable by app_reader

      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.ledger is evaluated for postgres, not for the role that selected from
      the view.
      Impact  If this view is reachable over an API as app_reader, a caller reads rows
              from public.ledger that the policies on that table were written to
              withhold — the view is an unfiltered path around them.
      Fix
          ALTER VIEW "public"."billing_overview" SET (security_invoker = true);
          -- Callers then need their own SELECT privilege on public.ledger, and the
          -- policies there apply to them.
      Docs    https://rebase.pro/docs/rls-check#view-bypasses-rls

  [critical] policy-always-true  public.documents · policy "documents_read"
      Policy "documents_read" on public.documents is USING (true) for app_reader

      This permissive SELECT policy's USING expression is a constant truth, so it
      matches every row for app_reader. 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 app_reader, a caller can read
              every row — the policy applies no scoping whatsoever.
      Fix
          -- Replace the constant with the scoping you intended, e.g.:
          ALTER POLICY "documents_read" ON "public"."documents"
              USING (user_id = auth.uid());
          -- or, if unconditional access really is intended, drop the policy and say so
          -- with an explicit grant instead:
          -- DROP POLICY "documents_read" ON "public"."documents";
      Docs    https://rebase.pro/docs/rls-check#policy-always-true

  [critical] rls-disabled  public.invoices
      public.invoices has row-level security disabled and is granted to app_reader

      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. app_reader holds
      DELETE, INSERT, SELECT and UPDATE on it.
      Impact  If this table is reachable over an API that connects as app_reader, a
              caller can read every row and delete, insert and update any row, with no
              tenant or owner scoping.
      Fix
          ALTER TABLE "public"."invoices" 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 "invoices_owner_select" ON "public"."invoices"
          --     FOR SELECT TO "app_reader" USING (user_id = auth.uid());
      Docs    https://rebase.pro/docs/rls-check#rls-disabled

────────────────────────────────────────────────────────────────────────────────────────
Summary

  critical 3   high 0   medium 0   low 0   info 0
  3 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-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