Storage of File with Sensitive Data Under Web Root

Description

Storage of File with Sensitive Data Under Web Root is a vulnerability that occurs when a product stores sensitive data in files located under the web document root directory without implementing sufficient access controls. The web root is the directory from which a web server serves files to clients, and files placed there may be directly accessible via URL requests unless explicitly protected. Sensitive files commonly found in web roots include database files, configuration files with credentials, backup archives, log files, source code, and temporary files. When web server access controls are misconfigured or not applied, attackers can directly request and download these files, gaining access to credentials, personal data, application logic, or other sensitive information.

Risk

Storing sensitive data under the web root creates severe security risks as it places protected information one URL guess away from exposure. Database files containing user credentials, personal information, and business data can be downloaded and analyzed offline. Configuration files may expose database connection strings, API keys, and encryption secrets. Backup files often contain complete copies of databases or source code. Application source code exposure enables attackers to find additional vulnerabilities through code review. Log files may contain session tokens, passwords entered in wrong fields, or debugging information. The risk is amplified by search engines indexing exposed directories, automated scanners discovering common file names, and backup tools creating predictably-named archives in accessible locations.

Solution

Store all sensitive data outside the web document root in directories that cannot be accessed via web requests. Configure the web server to explicitly deny access to sensitive file types (.sql, .bak, .log, .cfg, .env) even if accidentally placed in the web root. Implement a directory structure that separates public assets from application code, configuration, and data. Use web application frameworks that enforce this separation by default. Regularly scan the web root for sensitive files using automated tools. Configure backup processes to store files outside the web root with appropriate file system permissions. Disable directory listing in web server configuration. Implement monitoring to detect access attempts to sensitive file extensions.

Common Consequences

Impact	Details
Confidentiality	Scope: Confidentiality Attackers can directly access and download sensitive data files stored under the web root. This includes database contents, configuration secrets, personal information, and source code, leading to complete compromise of data confidentiality.

Example Code

Vulnerable Configuration (Directory Structure)

The following directory structure demonstrates a vulnerable web application layout:

/var/www/html/                    # Web root - all files potentially accessible
├── index.php
├── css/
├── js/
├── images/
├── config.php                    # VULNERABLE: Contains DB credentials
├── database/
│   └── users.db                  # VULNERABLE: SQLite database
├── backup/
│   └── site_backup_2024.zip      # VULNERABLE: Full site backup
├── logs/
│   └── application.log           # VULNERABLE: Log file with sensitive data
├── .env                          # VULNERABLE: Environment variables
├── .htaccess                     # May help, but often insufficient
└── admin/
    └── config.ini                # VULNERABLE: Admin configuration

<?php
// /var/www/html/config.php - Vulnerable: Directly accessible at /config.php
// Attacker visits: https://example.com/config.php

return [
    'db_host' => 'localhost',
    'db_name' => 'production_db',
    'db_user' => 'app_user',
    'db_pass' => 'SuperSecretPassword123!',  // Exposed!
    'api_key' => 'sk-live-xxxxxxxxxxxxx',     // Exposed!
    'encryption_key' => 'aes256-key-here'     // Exposed!
];

# Attacker discovery methods:
curl https://example.com/config.php
curl https://example.com/database/users.db
curl https://example.com/backup/site_backup_2024.zip
curl https://example.com/.env
curl https://example.com/logs/application.log

Fixed Configuration (Directory Structure)

/var/www/                          # Application root (NOT web root)
├── config/                        # SAFE: Outside web root
│   ├── config.php
│   └── .env
├── data/                          # SAFE: Outside web root
│   └── database/
│       └── users.db
├── logs/                          # SAFE: Outside web root
│   └── application.log
├── backups/                       # SAFE: Outside web root
│   └── site_backup_2024.zip
└── public/                        # Web root - only public files
    ├── index.php                  # Entry point
    ├── css/
    ├── js/
    ├── images/
    └── .htaccess

<?php
// /var/www/public/index.php - Only entry point in web root

// Configuration loaded from outside web root
require_once __DIR__ . '/../config/config.php';

// Database file is outside web root
$db_path = __DIR__ . '/../data/database/users.db';

// Process request...

# /var/www/public/.htaccess - Defense in depth

# Deny access to hidden files
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

# Deny access to sensitive extensions if accidentally present
<FilesMatch "\.(sql|db|sqlite|bak|backup|log|cfg|ini|env|yml|yaml|json)$">
    Require all denied
</FilesMatch>

# Deny access to PHP configuration files (except index.php)
<FilesMatch "^(?!index\.php$).+\.php$">
    Require all denied
</FilesMatch>

# Disable directory listing
Options -Indexes

# Nginx configuration for secure file handling

server {
    listen 443 ssl;
    server_name example.com;

    # Web root is public directory only
    root /var/www/public;

    # Deny access to hidden files
    location ~ /\. {
        deny all;
    }

    # Deny access to sensitive file types
    location ~* \.(sql|db|sqlite|bak|backup|log|cfg|ini|env|yml|yaml)$ {
        deny all;
    }

    # Only allow PHP execution through single entry point
    location ~ \.php$ {
        # Only allow index.php
        if ($uri !~ "^/index\.php$") {
            return 403;
        }
        fastcgi_pass unix:/var/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Disable directory listing
    autoindex off;
}

The fix places all sensitive files outside the web root, configures web server rules to deny access to sensitive file types as defense in depth, and uses a single entry point architecture.

---

Exploited in the Wild

Git Repository Exposure (.git folders, Ongoing)

Millions of websites have exposed their complete source code and commit history by deploying applications with .git directories accessible under the web root. Attackers use automated tools to detect and clone these repositories, extracting credentials, API keys, and vulnerability-revealing code. The .git/config and .git/logs/HEAD files are particularly targeted for reconnaissance.

• https://www.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexa-1m-sites-07-07-2015/

SQLite Database Downloads (Multiple CMS Platforms, Ongoing)

Content management systems and web applications using SQLite have suffered data breaches when database files were stored in web-accessible directories. Attackers discovered database locations through error messages, default paths, or directory scanning. Complete user databases including hashed passwords were downloaded and cracked offline.

• https://www.acunetix.com/websitesecurity/sql-injection/

WordPress Backup Exposure (Thousands of Sites, 2019)

Security researchers discovered thousands of WordPress sites exposing database backups in predictably-named files under the web root. Files like backup.sql, database.sql, and wp-content/backups/ contained complete database dumps with user credentials and content. Plugins creating automatic backups frequently stored them in web-accessible locations.

• https://www.wordfence.com/blog/2019/09/exposed-backups-databases-wordpress/

---

Tools to Test/Exploit

• DirBuster / GoBuster — Directory brute-forcing tools to discover exposed files and directories under web root.

• GitTools — Tools for finding and extracting exposed Git repositories from web servers.

• Nuclei — Vulnerability scanner with templates for detecting exposed sensitive files.

---

CVE Examples

• CVE-2005-1835 — Application stored data file containing sensitive information under web root.

• CVE-2002-1449 — Username and password stored in data file accessible under web root.

• CVE-2002-0943 — Database file accessible under web root allowed downloading of all user data.

• CVE-2005-1645 — SQLite database file stored under web root exposed to direct download.

---

References

1. MITRE Corporation. "CWE-219: Storage of File with Sensitive Data Under Web Root." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/219.html

2. OWASP Foundation. "Sensitive Data Exposure." OWASP Top 10. https://owasp.org/www-project-top-ten/

3. Apache HTTP Server Documentation. "Access Control." https://httpd.apache.org/docs/2.4/howto/access.html

4. Nginx Documentation. "Restricting Access." https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/