Exposed Paths Checker Guide
Use this guide to understand what the Exposed Paths Checker is validating, which path classes need urgent containment, and how to reduce publicly reachable exposure without confusing a low-risk response with a true leak.
Overview
An exposed path result is useful only when it helps you separate harmless noise from a location that should never have been reachable. The checker is trying to surface high-confidence sensitive locations such as admin paths, debug endpoints, backups, temporary artifacts, and misplaced configuration files.
Exposure classes worth prioritizing first
- Backups and archives: Old exports, ZIP files, SQL dumps, or deployment backups often deserve the most urgent containment.
- Admin and debug surfaces: Panels or temporary routes can reveal far more than intended.
- Misplaced config or repository files: Public access to .git or env-like artifacts should be treated as a containment issue immediately.
How to Classify an Exposure Finding
| Finding type | Typical severity | Expected action |
|---|---|---|
| Reachable backup or dump file | High | Remove or block access immediately, then check for downstream reuse. |
| Admin or debug route | Medium to High | Require auth, network restrictions, or remove it from the public edge. |
| Known path returns generic 404 | Low | Usually expected noise unless the response leaks useful implementation detail. |
| Configuration or repository file | High | Contain immediately and review whether source or secrets were exposed. |
Practical Blocking Examples
location ~* ^/(backup|dump|db|database)\.(zip|sql|tar|tar\.gz|gz)$ {
deny all;
return 404;
}
location ~ /\.(git|env|svn) {
deny all;
return 404;
}<FilesMatch "^(\.env|\.git|backup\.zip|dump\.sql)$">
Require all denied
</FilesMatch>Recommended Remediation Flow
- Classify the finding by sensitivity Separate harmless enumeration noise from publicly reachable admin, backup, or config locations.
- Contain first, investigate second Block or remove the exposure before spending time polishing the response behavior.
- Check deployment and build hygiene Many exposed paths exist because old artifacts were copied into the web root during deployment.
- Retest from the public edge Confirm the path is no longer reachable from the same route surface the checker used.
Troubleshooting Common Issues
The path still responds after a supposed fix
This often means a CDN, backup directory, or alternate virtual host is still serving the file.
- Test the exact public hostname and path again after deployment.
- Check for duplicate assets on old release directories or alternate roots.
- Verify the edge layer is not bypassing the new block rule.
The finding is a false positive or low-risk noise
Some guessed paths returning a clean 404 are expected and not urgent.
- Compare the response body and headers with a normal 404 baseline.
- Escalate only if the response leaks version, stack, or file-system detail.
- Prioritize truly reachable sensitive artifacts before cosmetic cleanup.
Validation Checklist
Post-fix validation
- Confirm the sensitive path is no longer reachable from the public hostname.
- Verify the response no longer exposes file names, stack traces, or directory hints.
- Review deployment roots and old releases for duplicate artifacts.
- Run the Exposed Paths Checker again and compare the high-confidence findings to the intended route surface.
FAQ
Should every guessed path be treated as a breach?
No. What matters is whether the path is genuinely reachable and what it exposes.
- A clean generic 404 is often low risk.
- A reachable backup, admin route, or config artifact is a higher-priority issue.
- Classify the response before escalating it.
Is returning 404 always enough?
Often yes, but the more important requirement is that the asset is not actually accessible.
- Deny or remove the file before worrying about status-code cosmetics.
- Make sure alternate hosts or release roots do not still serve it.
- Retest from the same public edge the user or crawler would hit.