The default error page of a web application should not display sensitive information about the product.

A Web application must define a default error page for 4xx errors (e.g. 404), 5xx (e.g. 500) errors and catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response.
When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks.

Primary

Implementation

Confidentiality
Read Application Data
A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

Implementation
Handle exceptions appropriately in source code.

Implementation
System Configuration
Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

Implementation
Do not attempt to process an error or attempt to mask it.

Implementation
Verify return values are correct and do not supply sensitive information about the system.

In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {try {...} catch (ApplicationSpecificException ase) {logger.error("Caught: " + ase.toString());}}

J2EE Misconfiguration: Missing Error Handling

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

7 Pernicious Kingdoms
2006-07-19
Draft 3
2006-07-19

Sean Eidemiller
Cigital
2008-07-01
added/updated demonstrative examples

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2008-10-14
updated Description

CWE Content Team
MITRE
2009-03-10
updated Name, Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-06-23
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated References

CWE Content Team
MITRE
2020-02-24
updated References, Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Weakness_Ordinalities

J2EE Misconfiguration: Missing Error Handling