Is your Supabase app's row-level security actually on?
Paste your public GitHub repo. In ~30 seconds you'll see whether your RLS policies are open to the anon key, whether a service-role key is committed, and exactly what to do about it. Free, client-side, no signup.
Reads public source only (migrations + env files), from your own browser. No database access, no credentials, nothing stored. Try it on a live example: load a demo repo.
What the scan checks
Committed secrets — service_role JWTs and sb_secret_ keys in env files (rotating them comes first, always).
Policies open to everyone — USING (true) with TO anon, TO public, or no TO clause at all (the "the policy name says Users but it means anyone" trap).
Write-all policies — USING(true) WITH CHECK(true) for authenticated, where any logged-in user can rewrite any row.
What it doesn't check: live runtime configuration, private repos, edge functions, storage rules. This is a public-source surface scan — full audits go deeper. See methodology.
If something turns up
RLS Spot Check
$99 fixed
Every table × every policy, rated: missing / permissive / correct
Committed-secret sweep of the repo
30-second verify query per finding
Written report, 48h turnaround
Full RLS Audit
$199 fixed
Everything in the Spot Check
Grants & role exposure review (the gates around RLS)
Write-path simulation on a fixture clone of your schema
Remediation SQL per finding + severity-ranked fix hours
Remediation
quoted after audit
We implement the fixes from the audit
Regression tests so the hole can't reopen
Priced per the report — no surprises
Request an audit
Email one line — your repo URL and which tier — and you'll get a confirmation with scope and turnaround within one business day.