Exposed sensitive files
Files like ".env" or ".git/HEAD" contain very sensitive information: database passwords, secret API keys, source code. This check ensures th…
Analyse my site for freeUnderstanding "Exposed sensitive files"
Certain files should never be publicly reachable, as they contain information that can fully compromise a site: database credentials (.env, wp-config.php, config.php), source code history with potential secrets (.git/HEAD), or full backups (backup.zip, backup.sql, database.sql). These files typically end up exposed by an oversight during deployment, or because the Git repository's root folder matches the web server's public folder.
Unlike a page that requires user action, these files are found automatically: bots continuously scan the internet for exposed .env files, knowing a single found file can potentially grant access to the entire infrastructure (database, cloud services, third-party API keys).
AWS_SECRET_KEY=AKIA...
↳ direct access to the whole infrastructure
How TheSiteFuse checks "Exposed sensitive files"
TheSiteFuse first fetches the homepage to measure its size (to detect false positives — see below), then tests 8 common sensitive paths: /.env, /.git/HEAD, /config.php, /wp-config.php, /backup.zip, /backup.sql, /.htpasswd, /database.sql. A file is considered exposed if it responds 200 with non-empty content. False-positive protection: some sites redirect all unknown URLs to the homepage (soft-404) with a 200 status — if the response size is within ±5% of the homepage's size, it is ignored to avoid wrongly flagging a "found" file.
Why "Exposed sensitive files" matters
- Full database compromise — an exposed
.envorwp-config.phptypically contains the host, name, user and password of the production database. - Access to cloud services — AWS, Stripe, SendGrid API keys, third-party tokens: their leak allows abuse billed to your account or access to data stored elsewhere.
- Source code leak — an exposed
.git/HEADoften allows reconstructing the entire Git repository history with tools like GitTools, revealing source code, accidentally committed secrets, and business logic. - Full backups — exposed
backup.sqlordatabase.sqldeliver all data (users, hashed passwords, personal information) in a single download.
Fix "Exposed sensitive files" step by step
Block sensitive files at server level
# Apache (.htaccess or vhost)
<FilesMatch "^\.(env|git|htpasswd)">
Require all denied
</FilesMatch>
<FilesMatch "\.(sql|zip|bak)$">
Require all denied
</FilesMatch>
# Nginx
location ~ /\.(env|git|htpasswd) {
deny all;
return 404;
}
location ~ \.(sql|zip|bak)$ {
deny all;
return 404;
}
Structural best practices
- The Git repository's root folder should never match the public web root.
.envand the.gitfolder must live outsidepublic_html/www. - Never store backups in a folder reachable by the web server — use separate storage (private S3 bucket, folder outside the web root).
- Systematically add
.env,*.sql,*.zipto your.gitignoreto avoid committing them by mistake. - Regularly check with
curl -I https://yoursite.com/.envthat none of these files respond 200.
Reference resource
To deepen your understanding of the technical concepts behind this check, see the dedicated Wikipedia article.
Wikipedia — Exposed sensitive filesDoes your site pass this check?
Run the free full audit (120 checks) and instantly discover what needs fixing.