I built a Supabase security tool, then found 14 critical leaks in my own production CRM
Quick story for anyone here running a SaaS on Supabase.
I've been shipping an open-source security auditor for Supabase (supabase-security on npm, ~4k weekly downloads, MIT). Probes anonymously to find RLS gaps, public storage buckets, SECURITY DEFINER functions exposed to anon.
This morning I added a --discover mode — keyless, walks your local repo, finds every table/RPC/bucket your app actually uses, then probes only those. Wanted to run it against my own production CRM as the final QA before announcing.
It found 14 critical leaks in my CRM:
- 7 tables that returned actual rows to anonymous callers (couriers, bot knowledge base, product variants, internal analytics)
- 6 SECURITY DEFINER functions that anyone with my public anon key could execute (dashboard stats, daily KPIs — the entire reporting surface)
- 2 listable storage buckets
Every single one had RLS technically "enabled" on the Supabase dashboard. Every SELECT policy was USING (true) applied to ALL roles, anon included. Server-side reads go through service_role so internally nothing broke. But the anon key sits in the JS bundle the moment someone opens devtools — anyone could have scraped the whole thing.
Generated the fix SQL, applied via the Management API, re-ran the audit. 14 → 0.
What I keep thinking about:
The Supabase dashboard "RLS enabled" checkmark tells you nothing about who can actually read what. You need to fire an HTTP request with the public anon key and inspect the response.
The under-priced risk on Supabase right now is RPC functions with SECURITY DEFINER + EXECUTE granted to anon. Most scanners don't even look at the RPC surface. Mine had 6 open. Several leaked admin-flavored data.
I had been emailing other people about THEIR leaked service_role keys for two weeks. Meanwhile my own project was bleeding analytics data to anyone with a curl command. Humbling.
If you ship on Supabase, this is 30 seconds:
npx supabase-security[@latest](/latest) --discover .
MIT licensed, nothing leaves your machine, no signup. Repo: github.com/Perufitlife/supabase-security-skill
Not pitching anything in this post — the CLI is free. Just curious if anyone else here has been bit by this same pattern.
This is a strong product insight because the real issue is not “RLS enabled or not.” It is false confidence.
A dashboard checkmark makes people think access is safe, but the actual risk lives in what anonymous callers can still touch through tables, RPCs, and buckets.
One thing I’d think about early is the name.
supabase-security is clear for GitHub discovery, but if this grows beyond a CLI into a real security product, the name may box it in as a Supabase-specific utility instead of a broader exposure/audit layer.
Something like Vroth.com would fit this direction better long term. It feels sharper, more security-native, and less like a repo name.