CWE-311 is straightforward: the product does not encrypt sensitive or critical information before storing or transmitting it.
It covers two separate surfaces. Data in transit crosses networks you do not control. Data at rest sits in files, databases, cookies and backups that someone else may eventually read. Both fall under this weakness, and it applies to every kind of product.
How it happens
No secure channel. An application exchanges sensitive information without TLS, or falls back to plain text in some circumstances. MITRE says an attacker with access to the network traffic can sniff packets from the connection and uncover the data, and notes this attack is not technically difficult.
Encryption skipped in storage. Credentials, personal data or health data are written as they are. MITRE's observed examples:
- CVE-2022-26390: a wireless battery product stores credentials and Personal Health Information (PHI) without encryption.
- CVE-2009-2272: a password and username stored in cleartext in a cookie.
- CVE-2009-1466: a password stored in cleartext in a file with insecure permissions.
- CVE-2009-0152: a chat program disables SSL in some circumstances even when the user says to use SSL.
The last example is easy to miss in review. The option exists, the user turns it on, and the code path still skips it.
# Vulnerable: plain HTTP carries credentials
requests.post("http://api.example.com/login", data={"user": u, "pass": p})
# Fixed: TLS with default verification
requests.post("https://api.example.com/login", json={"user": u, "pass": p}, timeout=10)
What an attacker gains
MITRE describes two outcomes. Confidentiality loss: sensitive data can be read by anyone with access to the traffic or storage. Integrity loss: omitting encryption on a network transfer should be considered on par with delivering the data to each user on the local networks of both sender and receiver, and it also makes it possible to modify the data in transit.
How to find it
MITRE's detection notes call for a mix of methods:
- Manual analysis. Deciding what counts as sensitive needs domain knowledge, so human review is useful, though coverage within limited time is partial.
- Automated analysis. Measuring the entropy of an input or output source can hint at whether it is encrypted, but a person still has to separate sensitive data from data that is intentionally unencrypted, such as metadata.
- Binary or bytecode analysis with disassemblers gives partial coverage.
- Dynamic analysis with web application, web services and database scanners gives partial coverage.
Practical checks you can do today: capture your own app's traffic with a proxy and look for readable credentials or personal data; list the files, cookies and tables that hold sensitive values and look at them directly; and search the code for http:// URLs and options that disable TLS.
How to fix it
MITRE's mitigations run from requirements through design to implementation:
- Decide what is sensitive. Clearly specify which data and resources need encryption, and require well-vetted encryption for any transmission or storage of them.
- Fit encryption into the design. Identify the separate contexts. One-way encryption works when only the recipient needs the key. Two-way encryption needs the key available, stored so only the intended user or the operating system can recover it.
- Assume another flaw will expose the data. Use threat modeling to decide where encryption helps most, and check that private data is not exposed through problems such as insecure permissions (CWE-732).
- Use strong, current, well-tested algorithms. MITRE says not to invent your own, and to check periodically for obsolescence. It names MD4, MD5, SHA1 and DES as once-trusted algorithms that are now considered weak.
- Use the techniques completely. Do not skip resource-intensive steps in approved methods, since those steps are often what blocks common attacks.
- Compartmentalize. Draw clear trust boundaries, keep sensitive data inside them, and apply least privilege.
- Make sensitive data easy to spot in code. Use naming conventions and strong types, and separate sensitive from non-sensitive fields, so unencrypted use stands out.
Encryption libraries are dependencies, and old ones go stale. A free in-browser dependency scan shows known advisories for up to 100 dependencies with no login, and the file never leaves your machine.
Quick check
Is HTTPS on the login page enough?
Only if everything sensitive travels over it. Check every endpoint, redirect, mobile call and background sync, because one plain HTTP path is enough to leak data.
Is base64 or other encoding a substitute for encryption?
No. MITRE notes that even when data is encoded in a way that is not human-readable, techniques exist to identify the encoding and decode it. Encoding is not secrecy.
How is CWE-311 different from CWE-312?
CWE-311 covers missing encryption in storage or transmission. CWE-312 is the narrower case of cleartext stored where another control sphere might read it.
