Cleartext Storage on Disk

This is CWE-313, the file-and-disk-specific instance of the broader cleartext-storage problem: sensitive data ends up written to a plain file on disk, unencrypted, where anyone with filesystem access (a compromised server process, a misconfigured backup, a forgotten log rotation policy) can simply read it. It's narrower than the general cleartext-storage-of-sensitive-information category in one useful way: because it's specifically about files, the externally observable version of this bug is directly testable whenever one of those files is ever accidentally exposed over the web, such as a debug log, a .env file, or a database dump left in a publicly reachable directory.

• Application log files that capture request bodies or headers containing credentials
• Configuration files (.env, config.php, settings.py) committed or deployed with real secrets inline
• Database dumps, backups, or exports left in a web-reachable directory
• Temporary files created during file processing or upload handling that are never cleaned up

• Probe conventional paths for accidentally-exposed files: .env, config.*, *.sql, *.log, *.bak, and similar extensions at the web root and common subdirectories
• Search for JavaScript bundles or source maps that reference internal file paths, which sometimes hints at where sensitive files are conventionally kept
• Where a log or debug file is reachable, scan its content for credential-shaped strings rather than assuming its mere presence is the whole finding

• No injected payload; this is a discovery-and-content-scanning check against files that shouldn't be reachable at all

Probe conventional paths and extensions associated with configuration, logging, and backup files, and for anything that returns real content rather than a 404, scan it for credential-shaped strings, connection strings, or API keys rather than treating mere reachability as the finding on its own. A .env file that's reachable but contains only placeholder values is a lower-severity finding (the file shouldn't be exposed regardless) than one that leaks a real, usable credential.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

An exposed file containing only example or placeholder values (DB_PASSWORD=changeme, API_KEY=your_key_here) is still worth flagging as an exposure risk, but shouldn't be scored as a confirmed credential leak the way a file with a real, structurally valid secret would be.

Manual Testing Methodology

Here is a systematic approach to identifying Cleartext Storage on Disk vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Cleartext Storage on Disk specifically, capture traffic on any link expected to be encrypted (including internal/service-to-service where reachable) to check for cleartext transmission, and probe signature or token-verification endpoints with a stripped, empty, or mismatched signature to see whether verification is actually enforced.

Compare the response against your baseline, looking specifically for sensitive data (credentials, personal information, session tokens) visible in plaintext on the wire or in storage, or a request with an invalid/missing signature that the server accepts as valid anyway.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Cleartext Storage on Disk, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Sensitive data stored or transmitted in cleartext is exposed to anyone with read access to the storage layer or the network path — a database backup, a misconfigured bucket, or a passive network observer on an unencrypted link all yield the data directly, with no cryptographic barrier to defeat first.

Broken cryptographic-signature verification is a related but distinct failure: even where encryption is used correctly elsewhere, a signature check implemented as a naive string comparison (rather than a constant-time comparison) or that accepts a malformed or absent signature can let an attacker forge tokens, licenses, or authenticated messages outright.

Both failure modes tend to surface only when it's already too late — in a breach post-mortem, a compliance audit, or a researcher's report — since neither one changes the application's normal behavior in a way that would be caught by functional testing alone.

Prevention and Secure Coding

Preventing Cleartext Storage on Disk takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Encrypt sensitive data at rest. Apply encryption to sensitive fields and backups at the storage layer, with key management separated from the data itself.

TLS everywhere, including internal traffic. Enforce TLS for all data in transit — between the client and the edge, and between internal services, since an internal network is not an implicit trust boundary.

Constant-time signature comparison. Verify cryptographic signatures using the crypto library's constant-time comparison function, never a plain ==/.equals() check, which leaks timing information an attacker can use to forge a valid signature byte by byte.

Keep TLS configuration current. Disable legacy protocol versions and weak cipher suites, and monitor certificate expiry actively rather than reactively.

Minimize what needs protecting. Don't retain or transmit sensitive data that isn't actually needed — the cheapest way to reduce cleartext-exposure risk is to reduce the surface that requires protection at all.