我之前也碰到过类似的容器行为差异问题，正好帮你理清这个点：

为什么会出现这种差异？ #

Tomcat 4.0.6的默认500错误页面由ErrorReportValve组件生成，它在处理异常消息时完全没有做HTML特殊字符的转义处理。所以当你抛出带XSS代码（比如<script>alert(1)</script>）的ServletException时，这些代码会直接原封不动输出到页面，被浏览器当成HTML执行。

而Tomcat 6.0.37及之后的版本，官方修复了这个安全漏洞：ErrorReportValve新增了HTML转义逻辑，会把消息里的<、>、"等特殊字符转换成对应的HTML实体（比如<、>），这样浏览器就会把这些内容当成纯文本显示，不会执行恶意脚本。

相关文档在哪里找？ #

你说没找到对应文档，其实这类容器实现细节的变更，主要记录在这几个地方：

• Tomcat对应版本的Release Notes：比如Tomcat 6的Release Notes里，会明确提到针对默认错误页面的XSS修复。你可以在Tomcat官方文档的版本专属板块找到这些记录。
• ErrorReportValve的类文档：这个组件是生成默认错误页的核心，不同版本的类文档会标注它的行为变化。比如Tomcat 6的ErrorReportValve文档就会说明它会对异常消息做HTML转义。
• Tomcat安全公告：这类涉及安全漏洞修复的变更，通常会出现在官方的安全公告里，专门记录针对XSS这类问题的修复措施。

另外要注意，你提供的javax.servlet.ServletException API文档本身不会规定消息的渲染方式——这是Tomcat作为Servlet容器的实现细节，不是Servlet规范强制要求的，所以规范文档里不会提这个点。

假设版本间存在清理差异的风险大吗？ #

非常大！ 这种风险绝对不能忽略：

• 如果你的应用跑在Tomcat 4.x、早期5.x这类未做防护的旧版本上，又用了默认错误页面，一旦异常消息里包含用户可控的内容（比如把用户输入的参数直接放进异常message抛出），攻击者就能构造恶意输入触发异常，在受害者浏览器里执行XSS脚本，窃取会话、篡改页面内容都不在话下。
• 就算是新版本Tomcat，如果你自己写了自定义错误页面，但没手动对异常消息做HTML编码，同样会踩XSS的坑。

最后给个小建议 #

最好的做法是升级到仍受支持的Tomcat版本（毕竟Tomcat 4、6早就停止维护了），同时不管用哪个版本，都要自定义错误页面，并且手动对所有输出到页面的内容做HTML转义，不要依赖容器的默认行为——毕竟自己控制的安全防护才最靠谱。

内容的提问来源于stack exchange，提问作者user1515381