u/renzom13

context: i posted here a few days ago about scanning 100 random supabase projects from github. 22% leak user data via the anon key. a lot of you asked if i could scan their projects too.

so here is the offer. completely free for first 20.

what i do:

• you give me the public URL of your supabase project (the https://abc.supabase.co one) and your anon key. nothing more.
• i run my open source CLI scanner against it from my machine.
• if i find anything (RLS off on a sensitive table, exposed schema, etc) i email you the findings with exact curl proof and the SQL to fix each one.
• if your project is clean i tell you that too. some projects ARE done right.

what i dont do:

• never read row contents. only counts via Range 0-0. that's enough to know if a leak exists.
• never publish your project name. ever.
• not selling a thing in this thread. ill mention my paid service ($99 fix-it-for-you) at the end of YOUR report if you want it. zero pressure. most people just fix it themselves once they see the findings, that's fine.

why free:

• im trying to build distribution for the open source scanner. each report you share back (anonymized) is social proof.
• found 3 critical leaks this morning doing this manually. one had service_role committed. one had 1843 user profiles readable by anyone. one had 1115 staff records exposed.
• i'd rather find them before some kid with a python script does and dumps them.

how to ask:

• drop your URL in a comment OR
• DM me your URL + anon key if you'd rather keep it off public log

ill work through them in order. 24-48h turnaround. if you read this 3 days from now and the spots are full ill probably do another batch the following weekend.

tool im using is open source if you want to skip the wait: npx @perufitlife/supabase-security --discover --url YOUR_URL --key YOUR_ANON_KEY. runs entirely on your machine, nothing leaves your terminal. that's also free, just no human eyes on it.

So I've been working on this open-source security auditor for Supabase projects for a few weeks. CLI tool, runs anonymously against your database, finds RLS gaps and SECURITY DEFINER footguns. ~4k weekly downloads on npm, MIT licensed.

This morning I shipped a new feature: a --discover mode that walks your local repo (no admin token needed), pulls every table / RPC / bucket reference from your source code, then probes only the surface your app actually uses.

I figured I should run it against my own production CRM as the final QA test before announcing the feature. Worst case it finds zero issues and I look smart.

It found 14 critical leaks.

7 tables that returned actual rows to any anonymous caller. 6 SECURITY DEFINER functions that anyone with my public anon key could execute (dashboard stats, courier analytics, daily KPI reports). 2 storage buckets that anon could list.

Every single one had RLS technically "enabled" on the dashboard. Every SELECT policy was USING (true) applied to ALL roles. The classic default-on-but-letting-everyone-in pattern. Server-side reads use service_role so they bypass RLS entirely — nothing internal broke. But the anon key sits in the JS bundle of my web app, so anyone who opened devtools could have scraped it all.

Spent the next 30 minutes generating the fix SQL, applied via the Management API (since local migrations are out of sync with prod), re-ran the audit. 14 -> 0.

Three things I keep replaying in my head:

1. The dashboard green checkmark for "RLS enabled" tells you almost nothing. You need to actually fire an HTTP request with your public anon key and see what comes back.

2. I wrote the check for this exact pattern six weeks ago. I was still vulnerable. Tools that don't catch yourself aren't done.

3. The under-priced risk on Supabase isn't leaked emails — it's RPC functions with SECURITY DEFINER granted to anon. Most scanners don't even look at those.

If anyone here ships on Supabase and wants to check theirs, the new mode is:

npx supabase-security@latest --discover .

Code is MIT, findings stay on your machine, no signups. Repo's at github.com/Perufitlife/supabase-security-skill if you want to look before running.

I'm honestly not even mad I found these. The tool worked. But I sat there for a minute looking at "14 critical" on my own project before I started fixing.

Context first since this turned into more than I expected:

Three weeks ago I scanned my own production Supabase project (Rotatepilot.com - aviation training app, paying users) and found 17 publicly readable tables. The anon key was in my JS bundle, RLS off on the wrong stuff, and anyone in the world with a 5-line curl could read user data. Mortifying.

I open-sourced the auditor I built to find that. Then I started wondering if this was just a "me" mistake or a category-wide pattern.

So I scanned 100+ random Firebase + Supabase + PocketBase projects pulled from public GitHub config files. Numbers from one slice (77 Firebase projects):

• 17 (22.1%) returned user data anonymously
• 11 of those leaked the `users` collection
• 4 leaked `posts`, 3 leaked `products`, 1 each leaked `orders` / `messages` / `profiles`

Same active-probe pattern shipped for 5 backends now. Each is a Node CLI you run locally + an MCP server companion if you live in Claude/Cursor:

• `npx supabase-security`
• `npx pocketbase-security`
• `npx appwrite-security`
• `npx nhost-security`
• `npx firebase-security`

All MIT, all run on your machine, never sees your data. HTML report with copy-paste fix snippets per finding.

What I learned about shipping in a "saturated" niche (security tooling):

1. **Most scanners infer leaks from policy metadata. Active probe is a 10x trust upgrade.** Showing someone "I just hit your endpoint as anon and got 200 with their data" lands in a way that "your policy might be wrong" doesn't.

2. **Default-rules-never-replaced** is the same pattern across ecosystems. PocketBase ships empty rules that allow nothing - good. Firebase ships test-mode rules expiring in 30 days that everyone changes to year 2099 instead. Supabase ships tables with no RLS until you toggle it. The category-level fix is education + tooling, not better defaults.

3. **People won't run a CLI to scan their own thing without a strong forcing function.** Even devs who star the repo don't follow up. The conversion lever is doing the audit FOR them as a free preview. I'm offering 5 free preview audits this week to validate.

Show HN went up just now if you want to follow comments: news.ycombinator.com/item?id=48081289

Repos: github.com/Perufitlife (5 `*-security-skill` repos)

Happy to take feedback - especially from anyone running PocketBase or Appwrite in prod, those have the smallest test set so far.Context first since this turned into more than I expected:

Three weeks ago I scanned my own production Supabase project (Rotatepilot.com - aviation training app, paying users) and found 17 publicly readable tables. The anon key was in my JS bundle, RLS off on the wrong stuff, and anyone in the world with a 5-line curl could read user data. Mortifying.

I open-sourced the auditor I built to find that. Then I started wondering if this was just a "me" mistake or a category-wide pattern.

So I scanned 100+ random Firebase + Supabase + PocketBase projects pulled from public GitHub config files. Numbers from one slice (77 Firebase projects):

• 17 (22.1%) returned user data anonymously
• 11 of those leaked the users collection
• 4 leaked posts, 3 leaked products, 1 each leaked orders / messages / profiles

Same active-probe pattern shipped for 5 backends now. Each is a Node CLI you run locally + an MCP server companion if you live in Claude/Cursor:

• npx supabase-security
• npx pocketbase-security
• npx appwrite-security
• npx nhost-security
• npx firebase-security

All MIT, all run on your machine, never sees your data. HTML report with copy-paste fix snippets per finding.

What I learned about shipping in a "saturated" niche (security tooling):

1. Most scanners infer leaks from policy metadata. Active probe is a 10x trust upgrade. Showing someone "I just hit your endpoint as anon and got 200 with their data" lands in a way that "your policy might be wrong" doesn't.

2. Default-rules-never-replaced is the same pattern across ecosystems. PocketBase ships empty rules that allow nothing - good. Firebase ships test-mode rules expiring in 30 days that everyone changes to year 2099 instead. Supabase ships tables with no RLS until you toggle it. The category-level fix is education + tooling, not better defaults.

3. People won't run a CLI to scan their own thing without a strong forcing function. Even devs who star the repo don't follow up. The conversion lever is doing the audit FOR them as a free preview. I'm offering 5 free preview audits this week to validate.

Show HN if you want to follow comments: news.ycombinator.com/item?id=48081289

Repos: github.com/Perufitlife (5 *-security-skill repos)

Happy to take feedback - especially from anyone running PocketBase or Appwrite in prod, those have the smallest test set so far.

**TL;DR:** I picked 77 random Firebase project IDs from public GitHub repos this morning and probed each anonymously for publicly readable Firestore collections. **17 of them — 22.1% — returned data with zero auth.** Built a free open-source auditor so you can check your own project.The repo: github.com/Perufitlife/firebase-security-skill---## What the leak distribution looks like23 collections leaked across the 17 projects:- `users` — 11 projects- `posts` — 4- `products` — 3- `messages` — 1- `profiles` — 1- `orders` — 1- + 2 moreThese are not theoretical "your rules might leak." These are HTTPS GETs against `firestore.googleapis.com` returning real document data with no auth header.## Why this happens (the boring honest answer)Firebase config is **never secret**. `projectId` is in your JS bundle. Every public app's project ID is one View Source away. The actual security boundary is your `firestore.rules` file.Three patterns I saw repeated across the 17 projects:**1. Test-mode never replaced**```match /{document=**} { allow read, write: if request.time < timestamp.date(2099, 1, 1);```Someone changed the date from 30-day default to "way in the future." Years later, still wide open.**2. Auth-only without ownership check**```match /users/{uid} { allow read: if request.auth != null;```Anyone signed in (even from a different app on the same Firebase project) reads every user record.**3. Public-read storage buckets**```match /b/{bucket}/o { allow read: if true;```Profile pics + receipts + uploaded docs, all anonymously enumerable.## The auditor`npx u/perufitlife5 minutes, no subscription, MIT licensed.If you want a cross-BaaS take I shipped equivalents for Supabase, PocketBase, Appwrite, Hasura/Nhost — every one of those ecosystems has the same "default rules ship open + nobody replaces them" pattern.Happy to take feedback, especially on the rule fixtures (`test-fixtures/` in the repo) — if there's a leak pattern I'm missing, I want to add it./firebase-security@latest` against your project ID + a service account read-only key. Probes the same patterns above, plus 8 more. Generates an HTML report with the exact rule snippets to copy-paste into `firestore.rules` to fix each finding.TL;DR: I picked 77 random Firebase project IDs from public GitHub repos this morning and probed each anonymously for publicly readable Firestore collections. 17 of them - 22.1% - returned data with zero auth. Built a free open-source auditor so you can check your own project.

Repo: github.com/Perufitlife/firebase-security-skill

What the leak distribution looks like:

23 collections leaked across the 17 projects.

• users: 11 projects
• posts: 4
• products: 3
• messages: 1
• profiles: 1
• orders: 1
• 2 more

These are not theoretical warnings. These are HTTPS GETs against firestore.googleapis.com returning real document data with no auth header.

Three patterns I saw repeated across the 17 projects:

1. Test-mode never replaced. Someone changed the default 30-day date to "way in the future" (timestamp.date(2099, 1, 1)). Years later, still wide open.

2. Auth-only without ownership check. allow read: if request.auth != null. Anyone signed in (even from a different app on the same Firebase project) reads every user record.

3. Public-read storage buckets. allow read: if true. Profile pics, receipts, uploaded docs all anonymously enumerable.

The auditor: npx firebase-security@latest against your project ID + a service account read-only key. Probes the same patterns above, plus 8 more. Generates an HTML report with the exact rule snippets to copy-paste into firestore.rules to fix each finding. 5 minutes, no subscription, MIT licensed.

I shipped equivalents for Supabase, PocketBase, Appwrite, Hasura/Nhost too. Every one of those ecosystems has the same "default rules ship open + nobody replaces them" pattern.

Happy to take feedback - especially on the rule fixtures (test-fixtures/ in the repo). If there is a leak pattern I am missing, I want to add it.

Built it after running into the same permission misconfig patterns over and over in production Hasura instances. Posted in r/Hasura too but figured this sub might care more about the GraphQL-specific bits.What it actually checks:1. anonymous role with open SELECT — filter is empty/{} so any unauthenticated GraphQL query reads every row of the table. Most common one.2. anonymous role with mutations — INSERT/UPDATE/DELETE for anonymous, almost never intentional3. user role with no row-level filter — every signed-up user can read/touch every row, ignoring ownership. Should be { owner_id: { _eq: "X-Hasura-User-Id" } } or similar.4. SELECT with all columns — exposes sensitive fields the role doesn't need5. Public schema introspection — anonymous can read __schema, lets attackers map the entire data model + permission structure without authThe active probe is what makes this different from passive scanners. After detecting the metadata pattern, it sends an actual anonymous GraphQL query against /v1/graphql and reports CONFIRMED with the row count + columns + bytes returned if data comes back. For introspection it sends `{ __schema { queryType { name } } }` — if anonymous can read that, it's flagged with the fact that the schema is fully visible.Pure Node.js, no deps, MIT. CLI + MCP server (for Claude Code/Cursor) + Apify actor.Repo: github.com/Perufitlife/nhost-security-skillIt's "nhost" in the name because Nhost was the test ground (their hosted Hasura is the easiest to audit), but it works against any Hasura instance.Curious about patterns I didn't code for. If you've seen Hasura permission misconfigs in the wild that aren't in my list, drop a comment — I'll add them as checks.Built it after running into the same permission misconfig patterns over and over in production Hasura instances. The active probe is what makes this different from passive scanners.What it actually checks:1. anonymous role with open SELECT — filter is empty/{} so any unauthenticated GraphQL query reads every row of the table.2. anonymous role with mutations — INSERT/UPDATE/DELETE for anonymous, almost never intentional outside specific endpoints.3. user role with no row-level filter — every signed-up user can read/touch every row. Should be { owner_id: { _eq: "X-Hasura-User-Id" } } or similar.4. SELECT with all columns (no allowlist) — exposes sensitive fields the role doesn't need.5. Public schema introspection — anonymous can read __schema, attackers map the entire data model without auth.Active probe: after detecting the metadata pattern, it sends an actual anonymous GraphQL query against /v1/graphql and reports CONFIRMED with row count + columns + bytes returned if data comes back. For introspection it sends a __schema query and flags if anonymous can read it.Pure Node.js, no deps, MIT. CLI + MCP server (Claude Code/Cursor) + Apify actor.Repo: github.com/Perufitlife/nhost-security-skill (the "nhost" prefix because Nhost was the test ground; works against any Hasura).Curious about patterns I didn't code for. If you've seen Hasura permission misconfigs in the wild that aren't in my list, drop a comment — I'll add them as checks.