Supabase RLS Security Scanner - Find Anonymous Data Leaks avatar

Supabase RLS Security Scanner - Find Anonymous Data Leaks

Pricing

from $4.65 / 1,000 security findings

Go to Apify Store
Supabase RLS Security Scanner - Find Anonymous Data Leaks

Supabase RLS Security Scanner - Find Anonymous Data Leaks

Supabase RLS security scanner. Probes a public Supabase project for Row-Level-Security misconfigurations and detects tables readable by the anon key - the #1 cause of Supabase data leaks. Returns row counts + a curl reproducer per finding. Counts only, no row data exfiltrated. By Renzo Madueno.

Pricing

from $4.65 / 1,000 security findings

Rating

0.0

(0)

Developer

Renzo Madueno

Renzo Madueno

Maintained by Community

Actor stats

0

Bookmarked

3

Total users

0

Monthly active users

4 days ago

Last modified

Categories

Share

Supabase RLS Security Scanner — Find Anonymous Data Leaks

Point it at a public Supabase project (URL + anon key) and it probes ~40 common tables for Row-Level-Security misconfigurations — the tables an anonymous caller can read straight from your frontend key. For Supabase developers and security-conscious teams auditing their own projects. Pricing: $0.02 per run + $0.005 per finding. A clean project costs 2 cents; a leaky one bills a few cents more per exposed table. No service-role key, no SSH, no install.

The 30-second check

The Supabase anon key is meant to be public — it ships in your frontend. The only thing keeping your tables private is Row-Level Security. Forget RLS on one table and its rows are readable by anyone on the internet with your URL + anon key. This scanner confirms whether that's true for your project, safely, and hands you both the proof and the fix.

Safe by construction: every probe uses Prefer: count=exact + Range: 0-0, so the scanner confirms a table is exposed and counts its rows without ever pulling row contents.

What a run returns

  1. Findings — per exposed table: row count, severity, the column list, flagged sensitiveColumns (e.g. email), and a verbatim curl reproducer (the exact request an attacker would run).
  2. A fix — the ALTER TABLE … ENABLE ROW LEVEL SECURITY statement plus a starter policy per leaky table.
  3. An HTML report saved to the run's key-value store as report.html, ready to forward to your team.
{
"projectRef": "abcdefgh",
"tablesProbed": 47,
"findings": [
{
"table": "profiles",
"readable": true,
"count": 1843,
"severity": "critical",
"sensitiveColumns": ["email"],
"reproducer": "curl 'https://.../rest/v1/profiles?select=*' -H 'apikey: <anon-key>' -H 'Range: 0-0' -I"
}
],
"summary": { "total_anon_readable": 3, "critical_count": 2, "total_exposed_records": 2074 }
}

Running it

{
"supabaseUrl": "https://your-project.supabase.co",
"anonKey": "eyJ...your-anon-public-key...",
"tableHints": ["billing", "invoices"],
"outputFormat": "both"
}
  • supabaseUrl / anonKey — from Supabase Dashboard → Project Settings → API. Use the anon/public key, never service_role.
  • tableHints — extra schema-specific tables to probe beyond the ~40 defaults (users, profiles, orders…).
  • outputFormatjson, html-report, or both (default).
  • Leave URL and key empty and click Run for a DEMO sample report showing exactly what a real scan produces — the safest way to try it first.

Ethical use

Scan only projects you own or have explicit written permission to test. The scanner is counts-only (never exfiltrates row data), and all findings stay private to the run owner unless you share them.

FAQ

Is it safe to run against my production project? Yes — it issues only count/head requests (Range: 0-0), so it confirms exposure and row counts without reading any actual data. It's the same anonymous GET an attacker could already make; running it changes nothing on your side.

Do I need my service-role key? No — and you should never paste it anywhere. The whole point is to test what the public anon key can reach. Only the anon key is used.

What counts as a billable finding? Each anonymously-readable table detected is one dataset item at $0.005; the run itself is $0.02. A fully locked-down project returns zero findings and costs just the $0.02 run.

Will it produce false positives? A finding means the anon key genuinely returned a non-error count for that table — i.e. it is readable. Some tables are meant to be public (a published blog, a product catalog); the report flags severity, but you decide which exposures are intended.

Can I try it without a project? Yes — leave both credentials empty for a demo report against a sample fixture.

What do I do after it finds a leak? Apply the emitted ALTER TABLE … ENABLE ROW LEVEL SECURITY + policy per table, rotate the anon key if data was exposed, and re-run to confirm clean. If you want it done for you, a turnkey audit + policies + key rotation is offered for $99 (money-back if nothing actionable), and weekly automated re-scans at rls-monitor.vercel.app.

Is there a free local option? Yes — the open-source CLI runs entirely on your machine: npx @perufitlife/supabase-security --discover --url <URL> --key <KEY> (source).

Sister scanners

Same family for other backends: Firebase, WordPress, Strapi, Directus, Payload, Convex, Hasura, PocketBase, Nhost.