Exposed Files Check
Enter a URL to check whether your web server is leaking files that should never be public: an .env with database passwords and API keys, a .git or .svn/.hg directory that lets anyone recover your source code, a Spring Boot Actuator endpoint that dumps your environment, a Tomcat Manager console, a phpinfo() page, an Apache server-status page, or a wp-config.php backup. Every check is a read-only GET, and a path is only flagged when the response body actually matches the artifact's signature — a plain HTTP 200 is never enough.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- .env / .env.local / .env.production files (database passwords, API keys, AWS secrets)
- .git, .svn and .hg repository data — full source code and history can be recovered
- Spring Boot Actuator endpoints (/actuator, /actuator/env, /actuator/mappings, /metrics)
- Tomcat Manager (/manager/html), phpinfo (/phpinfo.php) and Go pprof (/debug/pprof/)
- Apache server-status / server-info and a Prometheus /metrics endpoint
- Swagger / OpenAPI specs (/swagger.json, /openapi.json) and wp-config.php backups
- A .DS_Store directory index that leaks internal file and folder names
How to read the result
- OK = none of the checked paths are exposed (each returned a non-2xx status or a body that did not match the artifact).
- Critical (fail) = a secret-bearing file is readable with no authentication — an .env, a .git/.svn repository, an Actuator /env dump or a wp-config backup. Block it immediately.
- Warn = an admin/metadata surface is reachable — server-status, a Manager console, phpinfo, Swagger, pprof or /metrics. Restrict it to trusted sources.
- Each finding shows the exact path, the HTTP status, and the body signature that confirmed it, so you can reproduce it with curl.
- If the site answers 2xx for every path (a catch-all or single-page app), the path checks are skipped on purpose and reported as 'not tested' — that guard is what keeps the scanner from false-positiving.
Frequently asked questions
Why is an exposed .env or .git so dangerous?
An .env file typically holds database credentials, API keys and signing secrets in plain text — enough to take over the application. An exposed .git directory lets anyone reconstruct your entire source tree and its history, often revealing more secrets and the exact code paths to attack. Both are among the most common and most damaging web exposures.
Will this tool false-positive on a single-page app that returns 200 for everything?
No. Before probing, it requests a random non-existent path; if the server answers that with a 2xx (a catch-all / SPA / custom error page), the path checks are skipped and reported as not tested. And even on normal servers a path is only flagged when the response body matches that artifact's signature — never on the status code alone.
Is the scan safe and read-only?
Yes. Every request is a single GET; nothing is written, fuzzed, brute-forced or executed. It only fetches well-known paths and inspects a bounded slice of the response body to confirm whether the artifact is genuinely present.
How do I fix an exposed file?
Deny public access at the web server. For example, in nginx block the sensitive prefixes (location ~ ^/(\.git|\.env|server-status|actuator|manager) { deny all; return 404; }), move secrets out of the web root, and rotate any credentials that were exposed — assume a leaked secret is already compromised.
How is this different from the Web Server Audit?
The Web Server Audit grades your security headers, TLS redirect and cookie flags. This tool does one focused job: it hunts for publicly readable secret and admin files. Use both — headers harden the site, and this confirms no sensitive files are leaking.