Information Exposure Through an Error Message
Weakness ID: 209 (Weakness Base)Status: Draft
+ Description

Description Summary

The software generates an error message that includes sensitive information about its environment, users, or associated data.

Extended Description

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more deadly attacks. If an attack fails, an attacker may use error information provided by the server to launch another more focused attack. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • System Configuration
  • Operation
+ Applicable Platforms


PHP: (Often)


+ Common Consequences

Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.

+ Likelihood of Exploit


+ Detection Methods

Manual Analysis

This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints.

Effectiveness: High

Automated Analysis

Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible.

Effectiveness: Moderate

+ Demonstrative Examples

Example 1

In the following example, sensitive information might be printed depending on the exception that occurs.

(Bad Code)
Example Language: Java 
try {
catch (Exception e) {

If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem.

Example 2

The following code generates an error message that leaks the full pathname of the configuration file.

(Bad Code)
Example Language: Perl 
$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");
# avoid CWE-22, CWE-78, others.
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) {
ExitError("Error: $file does not exist");

If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.

+ Observed Examples
CVE-2008-2049POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
CVE-2007-5172Program reveals password in error message if attacker can trigger certain database errors.
CVE-2008-4638Composite: application running with high privileges allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file.
CVE-2008-1579Existence of user names can be determined by requesting a nonexistent blog and reading the error message.
CVE-2007-1409Direct request to library file in web application triggers pathname leak in error message.
CVE-2008-3060Malformed input to login page causes leak of full path when IMAP call fails.
+ Potential Mitigations

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can help an attacker craft another attack that now will pass through the validation filters.

If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

Phase: Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Phase: Build and Compilation

Debugging information should not make its way into a production release.

Phase: Testing

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Phase: Testing

Stress-test the software by calling it simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Phase: System Configuration

Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.

Phase: System Configuration

Create default error pages or messages that do not leak any information.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class200Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ParentOfWeakness BaseWeakness Base210Product-Generated Error Message Information Leak
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base211Product-External Error Message Information Leak
Development Concepts (primary)699
Research Concepts (primary)1000
CanFollowWeakness BaseWeakness Base600Failure to Catch All Exceptions in Servlet
Research Concepts1000
CanFollowWeakness ClassWeakness Class756Missing Custom Error Page
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant81Improper Sanitization of Script in an Error Message Web Page
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant201Information Leak Through Sent Data
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through error messages
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
7Blind SQL Injection
54Probing an Application Through Targeting its Error Reporting
+ References
Web Application Security Consortium. "Information Leakage". <>.
Brian Chess and Jacob West. "Secure Programming with Static Analysis". Section 9.2, page 326.. Addison-Wesley. 2007.
M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 16, "General Good Practices." Page 415. 1st Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 185. McGraw-Hill. 2010.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 194. McGraw-Hill. 2010.
+ Content History
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Relationships, Other Notes, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2009-01-12CWE Content TeamMITREInternal
updated Demonstrative Examples, Description, Name, Observed Examples, Other Notes, Potential Mitigations, Relationships, Time of Introduction
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative Examples, Potential Mitigations, Relationships
2009-12-28CWE Content TeamMITREInternal
updated Demonstrative Examples, Name, Potential Mitigations, References, Time of Introduction
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Error Message Information Leaks
2009-12-28Error Message Information Leak