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 in a production context this information is a potential security hole and it would be nice to disable it.

Thus I would like to know what the best (as in most straightforward/comprehensive) solution is to completely suppress Tomcat's default error pages. I am aware of the <error-page> option in web.xml, but it seems to fail on both desired counts, partly because I would have to list the same alternative error page many times (one for each response code I want to handle), and because this strikes me as possibly not 100% robust; if an attacker can somehow get an error code returned that I haven't explicitly listed, they would get the default error page.

Ideally, a simple option to set a universal custom error page, or to flat out disable sending any HTML along with the error code in the default error page, would be best. If neither of those options are possible, I'd be interested in finding out what the typical way to implement this functionality is (bonus points for discussing/showing why those hypothetical options don't exist, since it seems my requirement would be quite standard for anyone using Tomcat in production...).

Answer 1

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 2

<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 3

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