API Key Leak Detector

Prefixes make keys findable

Most providers give keys a recognisable prefix — sk_live_, ghp_, AKIA, AIza, xoxb- — precisely so leaked credentials can be detected. That helps defenders and attackers equally: automated scanners crawl public repositories continuously, and an exposed key is typically found and used within minutes of being pushed.

Rotate first, investigate second

The instinct is to delete the commit. That does not help, because the key was public and may already be copied. Revoke and reissue immediately, then check provider logs for use during the exposure window, then clean history. Any order that puts cleanup before rotation leaves a live credential in the wild during the response.

Deleting a commit does not remove it

Git history retains the blob, and on hosted platforms a pushed commit can remain reachable through the API even after a force push. Rewriting history with filter-repo or BFG is required, every clone and fork needs the same treatment, and a key that reached a public repository must be treated as permanently compromised regardless.

Where keys leak besides repositories

Client-side JavaScript, mobile app bundles, error messages and stack traces, log files, screenshots in tickets, CI build output, and public issue trackers. Anything shipped to a browser is public by definition, so a key in front-end code is exposed no matter how it is obfuscated.

Prevention that works

Environment variables outside version control, a gitignored env file with a committed example, a secret manager for anything shared, pre-commit scanning to catch keys before they are pushed, and scoped short-lived credentials so an exposure is bounded. Scoping matters most: a read-only key limited to one resource is a far smaller incident than an account-wide one.