CWE-210, Self-generated Error Message Containing Sensitive Information, applies when the product notices an error condition and writes its own diagnostic or error message that contains sensitive information.
It sits next to CWE-209. The difference is the author: here the product's own code builds the message, as opposed to an interpreter or framework producing it (that case is CWE-211).
How it happens
Someone writes a message that is meant to help debugging and puts the failing value, a path, a query or a credential into it. The message then reaches a screen or a log that others can read. MITRE's observed example is CVE-2005-1745, an information leak of sensitive information in an error message, with physical access required.
# Vulnerable: the message embeds the secret it was checking
if not valid_key(api_key):
raise ValueError(f"Bad API key {api_key} for account {acct_id}")
What an attacker gains
MITRE lists confidentiality: reading application data. Whatever the message contains is what the attacker gets.
How to find it
MITRE lists no detection methods for this entry. Search for error and exception constructors that build strings from variables, and check whether any of those variables can hold secrets, personal data or internal paths. Then trigger the errors and read the output.
How to fix it
MITRE's mitigation is that debugging information should not make its way into a production release, which applies both at implementation and in build and environment hardening.
- Write error text that names the problem, not the secret.
- Keep verbose output behind a debug flag that is off in production builds.
- Review logs the same way you review responses.
if not valid_key(api_key):
raise ValueError("Invalid API key")
Quick check
How is this different from CWE-209?
CWE-209 is the general case. CWE-210 is the part where your own code writes the message.
