BreachProbe scans a shipped app for database exposure

breachprobe.thecompound.tech

BreachProbe scans a shipped app's JavaScript, response headers, Supabase REST responses, and signed-in behavior, then shows what the app actually serves instead of stopping at a bundle search.

---

BreachProbe

The scan console

The main console shows one URL field, an authorization checkbox, and a "Scan free" control. It also keeps "NO ACCOUNT · NOTHING INSTALLED · READ-ONLY · ONE URL" beside the control.

The console sends the pasted address through the scan flow. It fetches the shipped page, reads its scripts, checks headers, probes database endpoints, and runs signed-in checks when the app supports them.

The severity filter

The report rail shows Everything, Critical, High, Medium, and Low filters. The worked report marks one critical finding, two high findings, three medium findings, and two low findings.

The filter changes which findings remain in the report river. BreachProbe keeps each finding's title, severity, evidence source, and written fix attached to the same result.

The run order

The console lists the scan in order: shipped JavaScript, exposed API keys, Supabase REST endpoints, security headers, broken-auth patterns, Stripe routes, and two signed-in users.

That order separates passive inspection from behavior tests. The scan reads code and headers first, then checks whether tables answer anonymous requests and whether one signed-in user can read another user's rows.

The sample report

The sample report shows a failing worked example with a critical row-level security finding. It identifies three affected tables and says the read crossed two signed-in users.

The report turns that result into a written SQL fix. It tells the reader to compare auth.uid() with the row owner column and to verify that a fresh user reads zero rows after the policy changes.

The method page

The method page explains what each probe sends and what answer counts as proof. It separates shipped-code patterns, response headers, Supabase REST reads, signed-in isolation checks, and Stripe route checks.

The JWT signing-secret check uses a different standard from a string match. BreachProbe recomputes the HS256 signature of the app's own public key, so a random 40-character build value does not become a finding.

The scan error state

The console keeps the four operating terms visible when a scan fails, then places the error on its own row underneath. The failed state no longer replaces the read-only and no-account explanation.

I changed ScanBar so the assurance text stays mounted independently of the error message. I also added the JWT signing-secret check to the deploy checks after the first implementation swallowed an ES module require error and reported a clean result for every fixture.