Sensitive file exposure is one of the most reliably impactful findings in external security audits. A single accessible .env file can expose database credentials, API keys, encryption secrets, and third-party service tokens simultaneously. The exposure is typically unintentional and often goes undetected because the files return HTTP 200 responses silently without producing any error logs or alerts.
This article covers the file types most commonly found exposed, how each one ends up publicly accessible, the concrete impact for each, and how to check your own deployment and prevent future exposure.
How Files Get Exposed
Files end up accessible on web servers through a small number of recurring patterns:
- Document root misconfiguration: The web server serves the entire application directory rather than just the intended public subdirectory. This is the most common cause of
.envand.gitexposure. A PHP application deployed with its root at/var/www/app/but the web server configured to serve/var/www/app/rather than/var/www/app/public/exposes every file in the project directory. - Deployment via Git pull to web root: Applications deployed by pulling a Git repository directly into the web-accessible directory automatically expose the
.git/directory. - Backup files placed in web root: Database backups, configuration snapshots, and archive files created directly in or near the web root for convenience during maintenance.
- Missing deny rules: Web server configurations that do not explicitly block access to non-public file types.
.env Files
Environment files are the highest-impact sensitive file type. A typical .env file for a modern web application contains database connection strings (including passwords), API keys for third-party services (Stripe, SendGrid, Twilio, AWS), authentication secrets (JWT signing keys, session secrets), and OAuth credentials.
# Example .env file contents — all of this is exposed if the file is accessible
DATABASE_URL=postgresql://app_user:s3cr3tpass@db.internal:5432/production_db
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SECRET=a9f3c2e1d8b7a6f5e4d3c2b1a0f9e8d7
NEXTAUTH_SECRET=PPQDLp2EIg9b4Ag1PWx3iR+DnTewL1w1m
GOOGLE_CLIENT_SECRET=GOCSPX-xxxxxxxxxxxxxxxModern frameworks generate multiple variants: .env, .env.local, .env.production, .env.staging, .env.development. Each is a candidate for exposure if the document root is misconfigured. WebDefect probes all common variants.
The impact of an exposed .env file is generally critical. Database credentials allow direct database access and exfiltration of all application data. Payment processor keys allow fraudulent charges. AWS keys with broad permissions allow complete cloud infrastructure compromise. All of these conditions persist until the credentials are rotated.
Git Repository Exposure (.git/)
When the .git/ directory is accessible via HTTP, the entire source code history of the application can be reconstructed by an attacker. The Git object store contains the complete contents of every committed file across all branches and the full commit history.
Even if secrets were removed from the codebase in a later commit, they remain in the Git history and are fully recoverable from the object store. Specifically, the following files reveal progressively more information:
/.git/config: Reveals the remote repository URL (which may be a private repository URL), branch names, and remote tracking configuration./.git/HEAD: Confirms which branch the deployed code is on./.git/COMMIT_EDITMSG: Shows the most recent commit message, which may contain references to internal systems, issue trackers, or sensitive changes./.git/logs/HEAD: The complete list of commit hashes, which can be used to reconstruct the full repository using Git's object retrieval protocol./.git/packed-refs: Lists all refs (branches, tags) with their commit hashes.
A web-accessible .git/ directory should be treated as a critical finding regardless of whether .env or other secrets are present in the history, because the full source code itself has significant security value.
Database Backups and Config Files
Database backups placed in the web root are another consistent finding. Common patterns:
/backup.sql,/dump.sql,/site.sql: SQL dumps created in the web root during migrations or maintenance./db.sqlite3: SQLite databases used in development or small deployments, sometimes deployed alongside the application code./backup.tar.gz,/backup.zip: Archive files containing application code and configuration./wp-config.php: WordPress configuration containing database credentials. PHP files are normally executed rather than served as text, but server misconfigurations can expose their source./config.php,/database.yml,/appsettings.json: Framework-specific configuration files.
Dependency Manifests and Lock Files
Dependency manifest files are lower severity than credential files but still reveal information useful for reconnaissance. An accessible /package.json or /composer.json reveals the complete dependency list with version numbers. Lock files (/package-lock.json, /composer.lock, /yarn.lock) reveal the exact transitive dependency tree. This information allows an attacker to identify vulnerable dependencies to target before performing any active exploitation.
An exposed /requirements.txt or /Pipfile.lock has the same implication for Python applications.
API Specification Files
OpenAPI (/swagger.json, /openapi.json, /openapi.yaml, /api/swagger.json) and GraphQL introspection endpoints expose the complete API surface including all endpoints, parameters, authentication requirements, and data schemas. This significantly accelerates targeted attacks by providing a complete map of the application's API.
API documentation access should be restricted to authenticated users or to internal networks. Public-facing API documentation that includes authentication endpoints, admin operations, or sensitive data fields provides unnecessary reconnaissance value.
Detecting Exposure on Your Own Site
Check for the most critical files with curl. A non-200 response or a response that matches your application's 404 page confirms the file is not accessible. A 200 response with recognizable content confirms exposure:
# Check .env file exposure
curl -sI https://example.com/.env
curl -s https://example.com/.env | head -5
# Check .git directory
curl -sI https://example.com/.git/config
curl -s https://example.com/.git/config | head -10
# Check database backup
curl -sI https://example.com/backup.sql
# Check WordPress config (should return 200 with PHP execution, not source)
curl -s https://example.com/wp-config.php | grep -i "DB_PASSWORD"
# If this returns content, the file is exposed as source codeBe aware that some applications return HTTP 200 with a custom 404 page for all missing paths. Compare the response body against your known 404 page content. A response that matches your 404 page for a sensitive file path means the file is not exposed.
Prevention
The primary preventions are structural rather than reactive:
- Correct document root: Configure the web server to serve only the public subdirectory (
public/,dist/,build/,htdocs/) rather than the full project directory. This is the most effective control because it makes the entire parent directory tree inaccessible regardless of what files are present. - Deny rules for sensitive paths: For nginx and Apache, add explicit deny rules for
.env,.git, and other sensitive patterns. - No secrets in the web root: Store database backups and configuration snapshots outside the web-accessible directory tree.
- No Git deployment to web root: Use a CI/CD pipeline that builds and copies only the necessary artifact files to the web-accessible location, rather than deploying by pulling the full repository.
# nginx: deny access to sensitive files and directories
location ~ /\.env {
deny all;
return 404;
}
location ~ /\.git {
deny all;
return 404;
}
location ~* \.(sql|bak|backup|zip|tar\.gz)$ {
deny all;
return 404;
}How WebDefect Detects Sensitive Files
WebDefect probes over 60 sensitive file paths as part of the sensitive file exposure phase. The scanner uses a baseline fingerprinting approach to reduce false positives: before checking any sensitive path, it requests a randomly generated nonexistent path to collect the application's 404 fingerprint (status code, content type, body size, and body content). Responses that match the 404 baseline are discarded, which eliminates the common false-positive case of applications that return HTTP 200 with a custom error page for all missing paths.
For files with known content signatures (the .env file contains DB_, API_KEY, or similar patterns; .git/config contains [core]), the scanner applies content verification before confirming exposure. A 200 response without matching content is not reported as a finding.
Confirmed exposures of credential-bearing files are reported as critical severity. .git directory access is reported as high severity. Dependency manifests and API specification files are reported as low to medium severity depending on content.