BreachProbe reads the JavaScript your site already serves the public, then counts the rows that come back
BreachProbe finds out whether the app you shipped leaks its database. You paste a URL, it reads the JavaScript your site already serves the public, and it comes back with a score, a letter grade, and every issue it found written out in plain sentences. It is for the person who built something with Lovable, Bolt, v0 or Supabase and now has real people's data sitting in it. The free scan needs no account, installs nothing, and only reads, though it does make you tick a box confirming you own the app or are authorised to scan it. The full report, which locates each finding table by table and gives you a written fix per issue, is $19. With thirty days of nightly re-scans and an email the moment something new appears, $39.
Watch the BreachProbe, Find out if your app leaks its database demo
The public key is not a secret, and that is the whole test
Most checks in this category answer one question: is row-level security switched on for this table. That is the rule deciding which rows each signed-in person is allowed to see, and reading the setting tells you only what someone intended.
BreachProbe does not read the setting. Your app hands its public key to every visitor, in the JavaScript, where anyone can copy it out. So the scan copies it out too and makes the request, table by table, the same way any stranger could, and counts what comes back. Zero is the only correct answer for a table that is meant to be private. Anything above zero is data your app just handed to a stranger who did nothing but view source.
The walk stops at thirty tables. A project with four hundred would otherwise hold the scan open for minutes.

What comes back, and what it means
A refused request looks like a failure and is the good outcome. The database's public API answers a properly filtered read with a normal success and an empty list, so the status code alone never tells you a table is open. Only rows do.
| What the read returns | What the report says |
|---|---|
| Request rejected, 401 or 403 or 404 | Blocked. This is the safe outcome |
| Success, zero rows | The rule is filtering, or the table is empty. Not a leak |
| Success with rows, to the public key anyone can copy out of your site | Anyone on the internet can read this table |
| No Supabase client in the shipped code | The probe could not run. Headers, secrets and pattern findings still stand |
When it cannot run, it says so
An app on a different backend ships no Supabase client, and the probe has nothing to talk to. The report names that, gives the reason, and does not score the app as though its tables had been read and held. On a security report, "we found nothing" and "we could not look" are different facts, and printing the second as the first is the worst thing the page could do.
The verdict runs free. The evidence is the paid half, and the split is structural rather than remembered: the free response is assembled from five fields per finding, and the one holding the table names is not among them. Free tells you that you have readable tables and how many. $19 tells you which ones, and hands you each fix already written as an instruction you can paste straight into Lovable, Cursor or Claude Code.
Scan an app free: https://breachprobe.thecompound.tech/hn?utm_campaign=compound
---
One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.