A free Supabase RLS audit: paste a URL, read the findings
RowShield runs a free audit of any Supabase project you control. Paste the project URL at rowshield.dev/audit and the probe examines the deployed public surface from outside; connect the project and the catalog scan reads its metadata and reports every access-control finding it holds. No signup stands between you and either half.
The claims on this page are the narrow, checkable kind: which requests the probe issues, what is and is not retained, what the findings look like, and where the free tier ends. Wherever a claim describes the scan, the matching query or behaviour appears next to it, because an offer page you cannot verify is only an advertisement.
RowShield does not detect this yet. This guide gives you the catalog queries to check it yourself. The nine rules that do ship are listed on the rules index.
What the audit covers
The outside-in half fetches your deployed pages, follows same-origin script tags and module preloads, and scans everything retrieved for Supabase credential shapes: legacy JWTs classified by decoding their role claim, sb_secret_ and sb_publishable_ keys, and sbp_ management tokens. A privileged credential sitting in browser-reachable code is reported critical with rotate-first guidance, because a key that bypasses every policy makes every policy irrelevant.
The same outside view then enumerates the tables PostgREST exposes and asks, for each, whether an unauthenticated request carrying only the public anon key returns rows. A table that answers yes is reported by name with its column count — never its contents. An empty reply is recorded as reachable rather than clean, because filtered-out and genuinely empty are indistinguishable from outside.
The connected half reads pg_catalog and bucket metadata through a catalog-read credential and evaluates the shipped rules: RLS disabled, always-true policies, enabled-with-no-policies, missing WITH CHECK, unindexed predicates, unwrapped auth calls, and public buckets. Platform schemas stay excluded — auth, storage, extensions and their siblings are suppressed so the first report remains readable.
-- One of the audit's catalog statements: metadata only, never rows.
SELECT n.nspname AS schema,
c.relname AS table_name,
c.relrowsecurity AS rls_enabled,
c.relforcerowsecurity AS forced
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p')
AND n.nspname = 'public';What it deliberately does not do
Stated plainly, because scope is the promise: RowShield does not automate anything beyond the checks listed above. There is no source-code review, no dependency scanning, no header or TLS analysis, no XSS testing and no compliance interpretation — the nine shipped rules plus the probe are the entire ceiling of automated claims, and this offer page holds no rule backing of its own because it describes the audit rather than detecting anything.
The probe cannot write. Its vocabulary is GET, HEAD and OPTIONS, enforced in code rather than by configuration, and before opening any socket it refuses loopback, RFC1918 and link-local ranges, CGNAT space and cloud-metadata endpoints — re-checked on every redirect hop. A mistyped URL that points inward fails closed.
What comes back, and what is kept
Findings arrive as they do in the product: one per rule violation, with severity, a plain-language rationale, and remediation SQL generated from your actual columns — owner-scoped, FORCE ROW LEVEL SECURITY included, ready to paste. Nothing is held back behind a plan; findings and generated fixes are never withheld on any tier.
Retention is deliberately thin. Leaked data is summarised as column names and counts, never values. Discovered keys are recorded as fingerprints — six characters and a length. Webhook URLs are stored masked, network failures resolve to fixed phrases rather than raw responses, and the introspection statements are module-level constants over pg_catalog with zero bind parameters, exported for audit.
From one scan to a standing check
The free audit needs nothing but a URL today. Keeping a project watched lands on the Free tier: one project, daily scans, email alerts, one seat. Paid plans change frequency and roster, never truth — hourly scans on Indie for three projects, fifteen-minute scans on Team for fifteen projects with Discord and custom webhooks and unlimited seats, and Growth above that, quoted individually. Rates are on the pricing page; until checkout opens it takes an email instead of a card and notifies you when it is live.
RowShield is an independent product, unaffiliated with and not endorsed by Supabase; Postgres, PostgREST and Supabase are referenced descriptively throughout this site. Run the free audit at rowshield.dev/audit — paste a URL, read the findings.
Frequently asked
- Is the free audit actually free?
- Yes. The public check costs nothing and needs no account — a project URL is the entire input. Connecting a project for scheduled scans starts the Free tier: one project, daily scans, email alerts, and findings are never withheld.
- Do you store my data?
- No rows are ever read. Exposed tables are reported by column name and count, keys are kept as fingerprints rather than values, and the probe issues GET, HEAD and OPTIONS requests only — nothing you paste is retained beyond the finding record.
- Why does a healthy project produce few findings?
- Because quiet is the intended result. A configured project answers the anonymous probe with permission errors and empty arrays, and the catalog scan finds owner-scoped policies. Few findings mean the checks ran and found posture worth keeping, not that the audit skipped anything.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit