J2EE Misconfiguration: Missing Custom Error Page
Weakness ID: 7 (Weakness Variant)Status: Incomplete
+ Description

Description Summary

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

Extended Description

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.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms



+ Demonstrative Examples

Example 1

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).

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

Handle exceptions appropriately in source code.

Always define appropriate error pages.

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

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

+ Other Notes

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. If the application shows the attacker a stack trace, it relinquishes information that makes the attacker's job significantly easier. For example, 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. 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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory4J2EE Environment Issues
Development Concepts699
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness ClassWeakness Class756Missing Custom Error Page
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Missing Error Handling
+ References
M. Howard, D. LeBlanc and J. Viega. "19 Deadly Sins of Software Security". McGraw-Hill/Osborne. 2005.
+ Content History
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other Notes, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Name, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-03-10J2EE Misconfiguration: Missing Error Handling