默认情况下，Tomcat的错误页面会公布Tomcat的存在以及处理请求的容器的确切版本。这对于开发很好，但是在生产环境中，这些信息是潜在的安全漏洞，禁用它会很好。减少Tomcat中的信息泄露错误页面
因此，我想知道什么是最好的（如最简单的/综合）解决方案是完全抑制Tomcat的默认错误页面。我知道web.xml中的<error-page>选项，但它在所需的计数上似乎都失败了，部分原因是我必须多次列出相同的备用错误页面（每个响应代码要处理一个），因为这可能不是100％稳健的;如果攻击者能以某种方式得到我没有明确列出的错误代码，他们将得到默认的错误页面。
理想的情况下，一个简单的选择设定一个统一的自定义错误页，或者平了禁止在默认错误页面的错误代码一起发送的任何HTML，将是最好的。如果这两种选择都不可行，那么我有兴趣了解实现此功能的典型方法（讨论/显示为什么这些假设选项不存在，因为看起来我的要求相当标准对于任何在生产中使用Tomcat的人...）。
<error-page>是正确的答案，但您不想只将所有错误代码重定向到某个通用消息。你必须考虑如何处理每个错误。如果您担心可能会错过其中一个代码，请查看HttpServletResponse interface中的常量。
一个可能的选择是建立一个Servlet过滤器，可能会重定向错误页面来正是你想要的网页...你只会这个代码一次，它会工作的所有的错误代码..
一个有趣的方法......我怀疑它可能有点脆弱*和*杀死性能，因为我需要解析每一个响应，试图从原始字符中解析出它是否是默认错误页面。还是有更好的方法来识别问题页面？ – 2009-10-05 16:44:24
@dtsazza关于性能，如果您比较了涉及整个请求处理过程的数十个指令中的几十条指令，则它不到0.1％。 **代码如此之高时，性能影响可以忽略不计**。 – KLE 2009-10-06 07:22:16
一些错误是直接由容器发送和您的应用程序不会有机会来对付他们。例如，当请求不存在的资源时，将发送404错误。您的应用程序可以做些什么的唯一方法是在web.xml中声明合适的<error-page>条目。
我与杰里米·斯坦同意<error-page>是正确的答案。所有的错误代码不是无限的。
阅读还讨论here，有关错误是如何与Spring MVC的处理。我认为最重要的是处理自己的错误（如果它们没有被捕获，将导致500内部服务器错误）。
我同意杰里米·斯坦因，即<错误页>是答案，但我想补充两点：
你应该把一个<错误页>项在CATALINA_HOME /conf/web.xml文件以及应用程序的web.xml文件，以防黑客尝试访问其他Web应用程序中的URL，例如默认安装的“manager”，“tomcat”，“examples”等。 。
如果你想确保它的服务器（显然）不是以汽车作为简单e这些错误页面。此链接有你需要做的事情的清单：
要做到这一点，最简单，最全面的方法是使用ErrorReportValve - 只是以下行添加到您的服务器的主机部分.XML（你应该已经AccessLogValve：
通过这种方式，你都躲在服务器信息和（因为可选showReport = FALSE）也将堆栈跟踪
。您可以在Security How To和Error Report Valve的文档中阅读更多信息。
但我有点想 - 因为它是一个独立的web应用程序，从用户的角度来看，无论是正在工作或他们不是;他们看到的实际响应实际上可能是通用的（日志会向技术人员显示实际问题以及HTTP响应代码仍然完好无损）。无论如何，接受你的答案是根据Tomcat可能发送的响应代码的枚举。 – 2009-10-06 08:02:44
在默认的tomcat安装中，默认安装了一堆webapps，例如， 'manager'，'host-manager'，'examples'，'tomcat'。看起来我需要为这些webapps中的每一个配置这组完整的错误代码，对吧？ – 2011-09-07 05:16:37
哦 - 我刚刚发现了CATALINA_HOME/conf/web.xml文件。我已经把放在了那里，但它仍然是一个问题，因为我不知道如何让tomcat找到引用的文件（或放置我的error.html文件的位置）。这意味着黑客会看到不同的结果，具体取决于他是否查询'/tomcat'与'/foo'，它至少会披露我正在使用tomcat。 –
2011-09-07 05:31:30