Leaked Secret Scanner

Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.

What counts as exposed — and what does not

The scanner probes a published list of well-known paths — /.env and its common variants, /.git/HEAD and /.git/config, configuration files, backup archives and key files — with plain public GET requests, exactly the requests an attacker, a search engine or a curious visitor could make. A path only counts as exposed when the response content matches what that file should actually look like: an env file must parse as key–value lines, a Git HEAD must look like a Git ref. Plenty of servers answer 200 for every path — single-page-app fallbacks, custom error pages, catch-all rewrites — and a 200 with your homepage HTML in it is not a leak. Those paths are listed separately on the result as responded but unconfirmed, so you can judge them yourself; this tool never calls an unconfirmed 200 a leak, and neither should any scanner you use.

Alongside the file probes, the scanner fetches the page itself and up to about fifteen of its JavaScript bundles and searches them for known secret shapes: cloud access key IDs, private-key headers, generic API key and token assignments, database connection strings and similar high-signal patterns. Client-side code is public by definition — anything shipped to a browser can be read by every visitor — so a real credential found in a bundle is exposed even though no file was misconfigured. Findings are reported by type, by source file and by occurrence count, with the value masked to at most its first four characters: enough for you to recognise which key it is, never enough for anyone reading the report to use it. The full secret is never fetched into, stored in or shown by this report.

Limits, stated plainly

This is a public, read-only probe of well-known paths, and its limits are part of the result. It only requests the paths on the published list — a secret in an unusually named file will not be found. It scans the landing page and roughly fifteen script bundles, not every asset on a large site, and it does not log in, crawl behind authentication, brute-force filenames or test anything that is not already reachable by an unauthenticated GET. Scans are rate-limited to 5 per hour per visitor and results are cached for 10 minutes, so a re-scan inside that window may show the cached verdict. A scan also runs to a time budget: when a slow target uses it up, the result is marked partial and says so — treat a partial clean result as “not fully checked”, not as “clean”.

If the scan finds something, the order of work matters more than speed of deletion. Rotate the credential first — revoke the exposed key and issue a new one — because copies may already exist in caches, archives and other people’s hands; deleting the file stops new downloads but does nothing about a key that is already out. Then remove or block the file at the server, purge CDN and proxy caches that may hold a copy, and check your access logs for earlier fetches of the same path. The companion article, exposed .env files and leaked keys, walks through the first-hour playbook attackers use and the full recovery sequence in order.

Neighbouring checks complete the picture: the Third-Party Script Audit covers the external scripts your pages load — a different supply-chain risk from your own leaked files — and the Security Headers Check grades the browser protections your responses carry. A note on method: a clean result means none of the probed paths answered with matching content and no known secret pattern appeared in the scanned files, at scan time, from the checker’s network position. It is evidence about those paths and files, not a guarantee about the whole server — keep the files out of the web root in the first place, and re-scan after every deployment change that touches what your server publishes.

The probe list, published

Frequently asked questions