Understanding CWE-219: Storage of File with Sensitive Data Under Web Root

Learn how CWE-219 exposes databases, config files, and logs to anyone on the internet when they are stored inside the web root directory.

Photo by Alexlion on Pixabay

Web servers deliver files to users through HTTP requests. These servers have a web root directory where public files like HTML pages, images, and JavaScript are stored. When a user requests a file from the website, the server looks in this web root directory and sends the file back. This makes the web root a public space where any file can potentially be accessed by anyone.

CWE-219 Overview

The Common Weakness Enumeration (CWE) is a list of software and hardware security weaknesses. The CWEs are numbered, and each one describes a specific type of mistake that could lead to a security vulnerability. Understanding these common weaknesses helps identify potential security problems, both for the developer and an attacker.

CWE-219 occurs when sensitive data files are stored in the web root directory but there are no access controls to prevent download. These files were never meant to be publicly accessible, but because they’re in the web root, attackers can request them directly through the browser. The weakness happens when developers don’t realize that web servers make those files publicly accessible.

Common examples include database files (SQLite databases, backup files), configuration files with credentials or API keys, log files containing sensitive information, data files with user information or passwords, and backup copies of source code or data. All of these might be stored in the web root for convenience during development but accidentally left there when the application goes to production.

This CWE is a variant of the more general parent CWE-552: Files or Directories Accessible to External Parties.

Example 1: Database File in Web Root

SQLite databases are single-file databases that are easy to use during development. Developers might place them in the web root for quick access:

/var/www/html/
├── index.php
├── about.php
├── contact.php
└── database.db        <-- SQLite database file

An attacker can easily download the entire database:

https://example.com/database.db

This is a weakness because the database file can contain user data, passwords, and application information. Once downloaded, the attacker has complete access to everything in the database.

Example 2: Configuration File with Credentials

Applications need configuration files that contain database credentials, API keys, and other settings. Sometimes these are stored in the web root for convenience:

/var/www/html/
├── index.php
├── admin.php
└── config.ini         <-- Configuration file

The config file could contain things like:

[database]
host = localhost
username = admin
password = password123

[api]
payment_key = sk_live_13HqWy3Kz9WDawowT1zdp7wm

This is a weakness because anyone can download https://example.com/config.ini and get the credentials and API key.

Example 3: Log Files

Applications generate log files to track errors, user actions, and system events. These logs might mistakenly be stored under the web root:

/var/www/html/logs/
├── error.log
├── access.log
└── debug.log

This is a weakness because log files can contain sensitive information like user sessions, failed login attempts with usernames, database queries with sensitive data, internal IP addresses and system paths, or stack traces revealing code structure. An attacker accessing https://example.com/logs/error.log can learn about the application's internals, as well as potential security issues.

What to Remember

The most important things about storing files with sensitive data under the web root are:

• The web root directory is public by default, and unless specifically protected, any file placed there can be accessed through a web browser
• Database files, configuration files, logs, and other sensitive files should never be stored in web-accessible directories
• Web servers will serve any file in the web root that doesn’t have specific access controls configured
• Attackers often guess common filenames and extensions to find exposed files (database.db, config.ini, .git/, etc.)
• The best practice is to always store sensitive files outside the web root entirely, where the web server can’t access them

Want to learn more about security weaknesses? I’m working through the CWE list and doing writeups for security challenges. Follow along for more articles like this one.