logo

Insertion of Sensitive Information into Externally-Accessible File or Directory

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application unintentionally stores confidential data—like passwords, API keys, or personal user details—in a location that is publicly accessible or readable by unauthorized users. Even if the file itself is intended to be available, the sensitive information within it should not be.

Extended Description

This flaw typically happens due to misconfigured file permissions, insecure default settings, or development practices that accidentally write secrets into log files, debug dumps, configuration files, or temporary directories. For example, an application might log full HTTP requests containing session tokens, or a deployment script could leave a backup file with database credentials in a web-accessible folder. Attackers can easily discover and exploit these exposed files using automated scanners or by guessing common file names. To prevent this, developers should implement strict access controls, ensuring sensitive files are stored outside web roots with proper permissions. Application code must avoid logging secrets, and automated processes should scrub sensitive data from any output. Regular security scans of publicly accessible directories are essential to detect accidental information leaks before they can be exploited.
Common Consequences 1
Scope: Confidentiality

Impact: Read Files or Directories
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Architecture and DesignOperationSystem Configuration
Do not expose file and directory information to the user.
Demonstrative Examples 1

ID : DX-179

In the following code snippet, a user's full name and credit card number are written to a log file.

Code Example:

Bad
Java
java
Observed Examples 1
CVE-2018-1999036SSH password for private key stored in build log
References 1
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Operation
Related Attack Patterns
Related Weaknesses
ChildOf: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
Notes
MaintenanceDepending on usage, this could be a weakness or a category. Further study of all its children is needed, and the entire sub-tree may need to be clarified. The current organization is based primarily on the exposure of sensitive information as a consequence, instead of as a primary weakness.
MaintenanceThere is a close relationship with Files or Directories Accessible to External Parties, which is more focused on weaknesses. As a result, it may be more appropriate to convert Insertion of Sensitive Information into Externally-Accessible File or Directory to a category.