"I accidentally committed an API key to GitHub" — what to do
This is the situation this scanner exists for, and the order of operations matters: rotate first, delete second.
- Assume it's compromised the moment it's public. Bots scan new public commits within seconds. Rotate the key (generate a new one and revoke the old) at the provider — AWS, Stripe, Google, a database, wherever it belongs. This is the only step that actually stops the leak.
- Then remove it from history. Deleting the key in a new commit is not enough — it still lives in the git history. Rewrite history (e.g. with
git filter-repo) or, for a small repo, consider it burned and start fresh. But rotating first is what protects you; history cleanup is housekeeping. - Keep it from happening again. Move secrets to environment variables or a secrets manager, add them to
.gitignore, and use a pre-commit hook or CI check so a key can't be committed in the first place.
How exposure detection works
Publicly reachable secrets usually leak through predictable paths: a committed .env file served by the web server, an exposed .git folder, a public backup or database dump, or an API key hard-coded into front-end JavaScript that anyone can read. This tool checks a site you own for those exposure patterns and flags secret-shaped strings in its public HTML and scripts. Any secret it finds is always masked — it never returns a usable credential — and results are not stored.
Use it only on sites you own or are authorized to test. It's a defensive check to catch your own mistakes before someone else does, not a tool for probing other people's sites. To review the wider security posture of a site — certificate, headers, exposed services — run a full Website Check alongside it.