Only apps you own
Before the first attack, you prove the app is yours. Until then, Keybrum only looks at what any browser already downloads (the page and its JavaScript), and shows counts, never which keys or tables.
- A tag on your page:
<meta name="keybrum-verification" content="…">. - A DNS record: a TXT record at
_keybrum.your-domain. On Cloudflare, one authorization page adds it. - A file at
/.well-known/keybrum-verify.txt.
A domain can change hands, so tags, DNS records and files are checked again every 30 days. When the proof is gone, attacks pause and the workspace is told why.
The backend must belong with the app. Proving you own a domain does not prove you own the Supabase or Firebase project its code points to. Before attacking a backend, Keybrum checks that it is tied to the verified domain: Supabase Auth must redirect to it, Firebase must list it among its authorized domains. Otherwise nothing on that backend is attacked, and the report says how to fix it.
No private networks. Hosted Keybrum refuses private and internal addresses. DNS answers are checked on every connection and every redirect, so a public name that resolves to an internal address is refused too.
Proof without the data
When a table, a bucket or an API answers a stranger, Keybrum keeps what proves it and drops the rest. Files are proven by downloading their first byte.
- the number of rows or files, and the column names;
- one example row, redacted: emails, phone numbers, names, addresses, tokens and IDs are masked before anything is stored;
- the request that proves it, so you can replay it yourself.
Database error details can contain a real row, so they are redacted too. Database functions are called over GET only, which the database runs read-only. API routes named like actions (send, delete, pay) are never called.
Tests that write nothing
Whether a stranger can add or change data is tested without adding or changing anything:
- Supabase: the insert or update is sent with the primary key set to null. Postgres checks Row Level Security before the not-null rule, so a not-null error proves the policy let us in, and no row can be written.
- Firebase: the update targets a random document that does not exist, with a precondition that it must exist. Security rules are checked first, so a “not found” answer proves write access, and nothing is created.
- Storage: the upload is sent to a path that already exists, without permission to overwrite it. An “already exists” answer proves the policy let us in; the existing file is untouched.
Canaries, only if you turn them on. Some flaws in your own API, such as one user reading or changing another user's object, can only be proven with a real object. If you enable active canaries in the app's settings (off by default), Keybrum creates a clearly marked object through your documented API, tries to reach it from a second account, restores any changed field, deletes the object and checks that it is gone.
Leaked keys, checked gently
When a secret key is readable in your JavaScript or in a table, Keybrum checks whether it works with a free, read-only call: listing the models an AI key can use, reading a balance. Nothing is spent, sent or changed. The finding then comes with the steps to rotate the key, because deleting it from the code does not un-leak it.
AI endpoints of your own are called only when their name says they are AI endpoints, with a five-word prompt.
Throwaway accounts
Many leaks only show to signed-in users. When your sign-up is open, Keybrum creates one ordinary account per app, the way a stranger would, with an address on its own domain, and reuses it on later runs. It never uses a real customer or admin account, and it does not place orders, send messages or change roles. Confirmation emails it receives are kept only as long as needed to confirm the account.
Your server's ports
When your app runs on its own server, Keybrum also checks the ports that should never face the internet: databases, the Docker API, admin consoles and the ports apps keep behind their reverse proxy. It first proves the server is yours: the address must serve your verified domain with this deployment's own files. Then it opens one connection per port and reads the greeting. It never sends or guesses a password, and when a database answers without one, it keeps only a count of databases. Apps on shared platforms such as Vercel, Netlify or Lovable are skipped: those servers are the platform's.
Light on your app
A full run sends tens of requests, rarely a few hundred, spaced to at most 12 per second on your host. When your app answers “too many requests”, Keybrum slows down and waits. This is not a load test.
Every request carries the User-Agent KeybrumScanner/0.1, so you can recognise it in your logs. About the scanner.
What Keybrum never does
- Attack an app before its owner proved ownership.
- Test delete access: there is no safe way to do it, and the report says it was not tested.
- Store the data it reads, beyond the one redacted example row.
- Run load tests, denial-of-service tests or brute force against your sign-in.
- Call your app secure. A clean run means the attacks in the library failed on that date; new attacks keep joining it.
What we store, and how
- Findings, with their redacted proof and their timeline, until you delete the app.
- The live feed of each run, deleted after 7 days.
- Leaked key values, test-account passwords and session headers, encrypted with AES-256-GCM, only so a retest can tell whether a removed key still works or sign in again.
- Session tokens and API keys as hashes only: we cannot read them back.
- Supabase, Vercel and Netlify tokens used for discovery, encrypted; a Supabase token used only to prove ownership is not stored at all.
Sign-in goes through Google or GitHub. Payments go through Polar; Keybrum never sees your card. More in the privacy policy.
Report a vulnerability in Keybrum
If you find a security issue in Keybrum itself, write to [email protected] with the steps to reproduce it. We acknowledge every report, keep you posted until it is fixed, and credit you if you wish.
Test only against your own account and workspace, don't access other people's data, and give us a reasonable time to fix before telling anyone else. Research done in good faith under these rules will not lead to legal action from us.
Report abuse
If you think Keybrum attacked an app you own without your permission, write to [email protected] with the address of the app and the time you saw the requests. We will look at who verified it, stop the attacks while we check, and close accounts that broke the acceptable use policy.
Keybrum Research
The guides, the CVE pages and the free tools are signed Keybrum Research: the team that writes Keybrum's attacks. The same rules apply to what we publish as to what we run.
- Primary sources. Every fact is checked against the vendor's documentation, the CVE record or the advisory before a page goes live, and those sources are listed at the bottom of each page.
- A separate check. Each page is fact-checked in its own pass, claim by claim against those sources, and corrected before it ships.
- Checks, not exploits. Pages show how to test your own app and how to fix it. They never give the steps to attack someone else's.
- Kept current. When a version, a default or a dashboard changes, the page is updated and its date says so.
Found a mistake? Write to [email protected] with the page and the source, and we will correct it.