CWE-550, Server-generated Error Message Containing Sensitive Information, starts from a simple observation by MITRE. Certain conditions, such as network failure, cause a server error message to be displayed. While error messages in and of themselves are not dangerous, what an attacker can glean from them might cause eventual problems.
How it happens
A server hits a failure it did not expect: the database is unreachable, a dependency times out, a request is malformed. The default behavior of many stacks is to describe the failure in detail. If that default reaches the user, the response may name internal hosts, software or paths.
What an attacker gains
MITRE lists reading application data as the confidentiality impact. The information is rarely a secret on its own. It is reconnaissance: what software runs here, how it is arranged, which failure produces which text.
How to find it
- Break things on purpose in a test environment. Stop the database, block a dependency, send malformed requests.
- Read what the user would see.
- Review the framework's default error configuration for production.
How to fix it
MITRE recommends designing and adding consistent error handling mechanisms capable of handling any user input, giving end users meaningful detail, and preventing error messages that might provide information useful to an attacker from being displayed.
- Handle errors in one place, with one policy. See our guide to missing standardized error handling.
- Show users a short, helpful message and a reference ID.
- Log the full detail on the server under that ID.
- Check the production configuration, because defaults often favor debugging.
Quick check
If an error message has no password in it, is it harmless?
Not necessarily. Details about software and structure help an attacker plan. Show users only what they need to act on.
