Website Security
Exposed Files Scanner
Requests 85 sensitive paths and confirms real exposure by matching file signatures while suppressing generic soft-404 pages.
What is Exposed Files Scanner?
Exposed files are sensitive files that end up publicly reachable over the web when they should never leave your server — environment files holding API keys and database passwords, .git directories exposing your full source history, database dumps, backups, and config files. They usually leak by accident: a deploy that copies too much, a misconfigured web root, a forgotten backup left in a public folder. Anyone who guesses the path can download them.
What Nandix checks
- Environment & secrets files and application config
- Version control and CI/build metadata (.git, CI manifests)
- Database dumps, backups, and dependency manifests
- Admin/debug endpoints, server-info, and OS/editor artifacts
- Discovery files (robots.txt, sitemap.xml) — flagged only when they advertise internal/admin paths
Probes
85 checks
How it detects
Passive GET requests. A 200 counts as exposed only when the body matches the file's expected signature AND is not the site's generic response. Genericness is decided by Jaccard token-similarity (≥ 0.9) against status-matched baseline samples, after echoed request paths are stripped — so hosts that 200 (or 401/403) every unknown path do not produce false positives. 404/410, redirects, and unmatched 200s are treated as safe.
Why it's dangerous
A single exposed .env file can be game over — it typically contains database credentials, third-party API keys, and signing secrets, handing an attacker everything at once. An exposed .git folder lets someone reconstruct your entire source code, including any secrets committed to history. These aren't theoretical: automated bots scan the internet around the clock requesting exactly these paths, so an exposed secret is often found within hours, not months.
Example finding
GET /.env returns environment variables including database credentials and API keys — fully readable by anyone.
How to fix it
Keep sensitive files out of the web root and deny them explicitly. Never place secrets in a publicly-served directory — environment files and config belong outside the web root entirely. Block dotfiles and sensitive paths at the server/proxy — deny .env, .git, .svn, backups, and dumps. Audit your deploy so it doesn't ship .git, local backups, or editor artifacts to production. Rotate any secret that was ever exposed — assume a leaked credential is already compromised.
nginx
# nginx — deny sensitive paths
location ~ /\.(env|git|svn|htpasswd) {
deny all;
return 404;
}
location ~ \.(sql|bak|backup|dump|old)$ {
deny all;
return 404;
}Severities & standards
Severities
CRITICAL · HIGH · MEDIUM · LOW
References
Frequently asked questions
How do bots find exposed files if the paths aren't linked anywhere?
They don't need links — they request a fixed list of common paths (/.env, /.git/config, /backup.sql) against every site. Not linking to it is not protection; the path is guessable.
I found an exposed .env — is changing the file location enough?
No. Move it out of the web root and rotate every credential inside it. If it was reachable, assume it was already downloaded.
Does Nandix download my files?
Nandix requests the path and checks whether the response matches a known sensitive-file signature. It confirms exposure without harvesting the contents, and it suppresses false positives from sites that return a 200 for every path.
See how every check runs on the methodology page, or browse all scanners.
Scan your site for this →Free exposed-files scanner. Nandix checks 85 sensitive paths — .env, .git, backups, config, admin endpoints — and confirms real exposure while suppressing false positives from soft-404 pages.