The default error page of a web application should not display sensitive information about the software system. 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. 699 Category ChildOf 4 1000 699 Weakness ChildOf 756 700 Category ChildOf 2 711 Category ChildOf 728 888 Category ChildOf 895 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. Architecture and Design Implementation Confidentiality Read application data Implementation Handle exceptions appropriately in source code. Implementation System Configuration Always define appropriate error pages. 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). Java Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { ... } catch (ApplicationSpecificException ase) { logger.error("Caught: " + ase.toString()); } } M. Howard D. LeBlanc J. Viega 19 Deadly Sins of Software Security McGraw-Hill/Osborne 2005 J2EE Misconfiguration: Missing Error Handling 7 Pernicious Kingdoms 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 J2EE Misconfiguration: Missing Error Handling