Exposure scanning

A small, fixed list of things that are almost always a mistake when they are publicly reachable:

• An exposed .git directory. Your entire source history, including whatever was committed and later removed.
• A readable .env file. Database URLs, API keys, signing secrets.
• Directory listings — an index of files nobody meant to publish.
• Common administrative paths that answered when they should not have.
• Public source maps referenced by the page, which hand a reader your unminified front-end source.
• Mixed content — http assets on an https page, which browsers block and attackers can substitute.
• Version-disclosing headers, like a Server or X-Powered-By that names your exact framework version.

Request budget

30 per run

Timeout

30 seconds

Attempts authentication

Never

Requires confirmation

Yes

Findings are matched on content, not just status code. A site that serves a styled 404 page with a 200 status for everything would otherwise report every path as a hit.

This is the part worth being explicit about.

The scan tests reachability only. It requests a path and looks at what came back. It never submits credentials, never attempts to bypass authentication, never tries an injection of any kind, and never attempts to exploit anything it finds. There is a hard cap of thirty requests for an entire run.

“This file is downloadable by anybody” is a complete, actionable finding. Going further would not tell you more, and it would make the tool something you could not responsibly point at a production system.

Requests for /.git/config and /.env look exactly like an attack in your access logs, because that is what an attack looks like. Running this may set off your own WAF, your intrusion detection, or an on-call alert belonging to somebody else.

So the check will not run until you confirm you are authorised to scan the target. Not a checkbox in a settings page you ticked a year ago — a per-suite confirmation, stored with the configuration, that has to be there before the scan will start.

Every request also carries an identifying user agent, so when somebody does go looking through the logs, the traffic is traceable back to a tool rather than mysterious.

Scan targets and the links found on a page are, from our side, untrusted input being fetched from inside our network. Requests are resolved through a guard that refuses loopback, private and link-local addresses, and every redirect hop is re-checked rather than trusted because the first one looked fine.

It is a detail no user should ever have to think about, which is precisely why it is worth building properly.