Reducing information disclosure in Tomcat error pages

Question

By default, Tomcat\'s error pages disclose both the existence of Tomcat and the exact version of the container that\'s handling the requests. This is nice for development, but

Answer 1

I agree with Jeremy Stein, that <error-page> is the answer, however I'd like to add 2 points:

1. You should put an <error-page> entry in the CATALINA_HOME/conf/web.xml file, in addition to the application's web.xml file, in case the hacker tries to access URL's in other web-apps such as the default-installed 'manager', 'tomcat', 'examples' etc..

2. If you want to secure the server it's (evidently) not as simple as taking care of these error pages. This link has a list of things you need to do:

https://www.owasp.org/index.php/Securing_tomcat

Answer 2

A possible option would be to set up a Servlet Filter, that could redirect error pages to exactly the page you want ... You would only code this once, and it would work for all error codes..

Answer 3

<error-page> is the right answer, but you don't want to just redirect all error codes to some generic message. You have to think about how you want to handle each error. If you're afraid you might miss one of the codes, check out the constants in the HttpServletResponse interface.

Answer 4

The simplest and most comprehensive way to do this is using the ErrorReportValve - just add the following lines to the Host section of your server.xml (where you should already have the AccessLogValve:

<Valve className="org.apache.catalina.valves.ErrorReportValve"
    showReport="false" 
    showServerInfo="false"/>    

In this way you are hiding the server info and (because of the optional showReport=false) also the stack traces.

You can read more about this in the Security How To and in the documentation of the Error Report Valve.

Answer 5

Some of the errors are sent directly by the container and your application doesn't have a chance to deal with them. For example, when a non-existent resource is requested, the 404 error will be sent. The only way your application can do something about it is to declare the appropriate <error-page> entry in the web.xml.

I agree with Jeremy Stein that the <error-page> is the right answer. After all the error codes aren't unlimited.

Read also the discussion here, about how errors are handled with Spring MVC. I believe that it is most important is to handle your own errors (the exceptions that if they don't get caught will result in a 500 Internal Server Error).