Exposed Sensitive Files (.git, .env, Backup Files)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / Information Disclosure
Typical Severity Critical
OWASP A05:2021 – Security Misconfiguration
CWE CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory; CWE-548: Exposure of Information Through Directory Listing
Also known as Sensitive File Disclosure, Credential Exposure, Source Code Leakage, Backup File Exposure
Affected systems Web servers (Apache, Nginx, IIS, Caddy), any application deployed via Git, any environment using .env-style configuration files, CMS platforms (WordPress, Laravel, Django, etc.)
Common file targets .git/, .env, .env.local, .env.production, web.config, .htaccess, *.bak, *.old, *.sql, *.tar.gz, *.zip, database.yml, config.php

Overview

Exposed sensitive files occur when files or directories that contain confidential information — such as version control metadata, environment variables, cryptographic keys, or database dumps — are accessible via HTTP(S) without authentication or access controls. This is a server-side misconfiguration, not an application-layer vulnerability: the data was never intended to be served to the public, but the web server does not restrict access to it.

Three of the most commonly exploited file classes are:

  • .git directories: When a Git repository is deployed by copying the working directory to the web root, the .git/ folder — containing the full commit history, object database, configuration, and remote URLs — is served publicly. Tools such as git-dumper can reconstruct the entire source tree from an exposed .git/ directory.
  • .env files: Popularised by the Twelve-Factor App methodology and frameworks such as Laravel, Symfony, Django, and Node.js, .env files store runtime secrets (database credentials, API keys, OAuth tokens, encryption keys) as plain-text key-value pairs. A single HTTP GET to /.env can expose every secret in the application.
  • Backup and archive files: Developers and sysadmins sometimes leave backup copies of configuration files or the entire web root on disk (e.g., config.php.bak, site.tar.gz, dump.sql). Web servers serve these files like any static asset, giving attackers a direct download of credentials or full database contents.

Sensagraph automatically probes for hundreds of known sensitive file paths during its continuous scanning process.

How it works

Attackers use automated scanners and manual probing to enumerate known paths on a target origin. The HTTP response code and response body determine whether a file is present and accessible:

  • A 200 OK response with a non-empty body confirms the file is publicly accessible.
  • A 403 Forbidden response confirms the path exists but is restricted — still an information leak, as it reveals directory structure.
  • A 404 Not Found response is the desired baseline indicating the resource does not exist or is not reachable.

.git/ reconstruction attack

Even without directory listing enabled, an attacker who can access /.git/HEAD and /.git/config can infer the repository structure and iteratively download Git objects (/.git/objects/<sha>). Automated tools reconstruct the working tree locally, revealing full source code including hard-coded secrets, internal comments, and file paths. The PACK files at /.git/objects/pack/ can compress the entire repository into a single downloadable archive.

.env file exposure

Frameworks and deployment scripts often place .env at the application root, which may coincide with or be one level above the web root. A misconfigured document root or a missing deny rule exposes the file. Common entries include:

  • DB_PASSWORD, DB_HOST, DATABASE_URL — direct database access
  • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY — cloud infrastructure takeover
  • APP_KEY, SECRET_KEY — encryption key exposure enabling session forgery or decryption of encrypted data
  • STRIPE_SECRET_KEY, SENDGRID_API_KEY — third-party service abuse

Backup file exposure

Backup files are often created by text editors (e.g., index.php~, wp-config.php.bak), cPanel backup tools, or manual archiving. Their paths are predictable and easily guessed or enumerated from a wordlist. Because they are static files, no application-layer logic prevents their download.

Business impact

The consequences of sensitive file exposure range from credential theft to complete system compromise:

  • Full source code disclosure: Exposes proprietary business logic, unremediated vulnerabilities, and internal architecture to attackers.
  • Credential and secret leakage: Database passwords, API keys, and private keys extracted from .env or .git history enable lateral movement, data exfiltration, and infrastructure takeover.
  • Database compromise: Exposed SQL dumps provide attackers with plaintext or hashed user credentials, PII, payment data, and other regulated information — triggering GDPR, PCI-DSS, and HIPAA breach notification obligations.
  • Cloud resource abuse: Leaked cloud provider credentials (AWS, GCP, Azure) can be used to spin up infrastructure for cryptomining, launch further attacks, or incur significant financial charges.
  • Regulatory and legal liability: Unauthorized disclosure of personal data constitutes a reportable incident under GDPR (Article 33), with fines up to 4% of global annual turnover.
  • Reputational damage: Source code and credential leaks are frequently indexed by search engines or shared in threat intelligence communities, making the exposure public knowledge.

How to fix it

  1. Never deploy the .git/ directory to the web root. Use a CI/CD pipeline or deployment tool (e.g., rsync with exclusions, Deployer, Capistrano) that copies only the built application artifacts, not the repository metadata. If .git/ is already exposed, remove it from the web root immediately and rotate all secrets found in the commit history.
  2. Block access to sensitive paths at the web server level. Configure explicit deny rules before any accidental deployment can cause harm:
    • Nginx: location ~* /\.(git|env|htaccess|htpasswd|svn|DS_Store)(/|$) { deny all; return 404; }
    • Apache: <FilesMatch "\.(git|env|bak|old|sql|tar|gz|zip|log)$"> Require all denied </FilesMatch>
    • IIS: Add <requestFiltering> rules in web.config to deny requests to these paths.
  3. Keep .env files outside the web root. Store configuration files one or more directory levels above the document root (e.g., /var/www/app/.env when the web root is /var/www/app/public/). Update framework configuration to point to the correct path.
  4. Use a secrets management system. Replace file-based secrets with a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). Inject secrets at runtime via environment variables set by the process manager, not by a file on disk.
  5. Add sensitive file patterns to .gitignore. Ensure .env, *.bak, *.sql, *.tar.gz, *.log, and other sensitive patterns are listed in .gitignore and, critically, that they have never been committed. Use git log --all -- <filename> to audit history.
  6. Rotate all exposed credentials immediately. If a .env file or Git history exposure is confirmed, treat every secret it contained as compromised: rotate passwords, regenerate API keys, revoke and reissue certificates, and audit access logs for unauthorized use.
  7. Disable directory listing. Ensure Options -Indexes (Apache) or autoindex off (Nginx) is set globally so that directories without an index file return a 403 rather than a file listing.
  8. Implement a Web Application Firewall (WAF) rule. Add WAF rules to block requests targeting known sensitive paths (/.git/, /.env, /.htaccess, common backup extensions). This provides defence in depth alongside server-side controls.
  9. Perform regular file exposure audits. Include sensitive file path enumeration as part of routine security testing (penetration tests, automated scanning) to catch regressions introduced by deployments.

References

Frequently asked questions

Send an HTTP GET request to https://yourdomain.com/.git/HEAD. If the server returns a 200 OK response containing text such as 'ref: refs/heads/main', your .git directory is publicly exposed and must be restricted immediately. A 404 response indicates it is not accessible.

A 403 response is better than a 200, but it still confirms that the .git directory exists on the server. Depending on the web server configuration, individual files within .git/ may still be directly accessible even if directory listing is denied. The safest outcome is a 404 response, achieved by blocking the path entirely or not deploying .git/ to the web root in the first place.

This specific vulnerability concerns the .git directory being served publicly via HTTP. However, secrets committed to even a private repository can be exposed if that repository's working directory is later deployed to a publicly accessible web server with .git/ included. The exposure is at the web server layer, not the repository hosting layer.

Treat the incident as a confirmed credential compromise. Immediately rotate every secret listed in the file — database passwords, API keys, encryption keys, OAuth tokens, and any other credentials. Audit application and infrastructure access logs from the time the file was first deployed to identify unauthorized access. Notify relevant parties as required by applicable data protection regulations (e.g., GDPR Article 33).

Yes. Automated scanners routinely probe for predictable backup file names derived from known file names (e.g., index.php.bak, wp-config.php.old, config.php~). These wordlists are publicly available and widely used. Any file with a sensitive name and a common backup extension left in the web root should be considered discoverable.

Both. CMS platforms such as WordPress, Joomla, Drupal, and Laravel-based applications are common targets because their file structures and common file names are well-known. WordPress sites are frequently scanned for wp-config.php.bak, while Laravel applications are commonly probed for .env. Any web application deployed carelessly can be affected regardless of the underlying technology.