这个问题其实挺常见的——全局的web.xml错误页面配置生效了，但部分接口自己的错误处理逻辑“跳脱”了规则，直接输出了堆栈跟踪、应用版本这类敏感信息，确实存在安全隐患。我来给你几个可行的解决思路，从代码修复到全局管控都覆盖到：

1. 修正特定URL/API的异常处理逻辑 #

最直接的方式是找到这些“自作主张”输出敏感信息的代码，修改它们的错误处理逻辑：

• 如果是原生Servlet开发：检查这些URL对应的doGet/doPost方法里的异常捕获块，把原来输出堆栈的代码（比如e.printStackTrace()、将堆栈写入HttpServletResponse的操作）删掉，替换成转发到全局错误页面的逻辑：

  // 替换掉输出堆栈的代码
  request.getRequestDispatcher("/error404.jsp").forward(request, response);
  response.setStatus(HttpServletResponse.SC_NOT_FOUND);
  

• 如果用Spring MVC这类框架：为特定Controller添加@ExceptionHandler注解，统一处理异常并返回无敏感信息的响应；或者直接移除自定义的异常输出逻辑，让框架走全局错误处理流程。

2. 强制触发Servlet全局错误页面规则 #

Servlet规范里有个关键点：只有当代码调用response.sendError()时，才会触发web.xml里配置的error-page；如果只是用response.setStatus()然后直接写响应内容，就会绕过全局配置。
所以你可以把这些特定URL里的错误处理代码，从直接设置状态码+输出内容，改成调用response.sendError(404)，这样就会自动跳转到你配置的/error404.jsp，不会再泄露敏感信息。

3. 用全局Filter拦截并修正敏感响应 #

如果不想逐个修改代码，或者担心有遗漏，可以写一个全局Filter，拦截所有响应，检查是否包含敏感信息（比如堆栈跟踪关键词、版本号），如果有就替换成统一的错误内容：

• 实现Filter接口，用HttpServletResponseWrapper包装响应，捕获输出的内容；
• 判断内容中是否存在敏感关键词，如果存在就清空原有输出，转发到全局错误页面或者输出友好的错误提示。
  不过这个方法要注意性能，避免对正常响应造成影响，建议只针对可能出错的URL路径做拦截。

4. 框架层面统一管控（若使用框架） #

如果你的项目用了Spring Boot、Struts这类框架，可以直接通过框架配置关闭敏感信息输出：

• Spring Boot：在application.properties里添加配置，彻底禁止堆栈和版本号输出：

  server.error.include-stacktrace=never
  server.error.include-version=false
  server.error.path=/error404.jsp
  

• 传统Spring MVC：配置SimpleMappingExceptionResolver，指定异常对应的错误视图，同时关闭堆栈信息输出。

5. 代码审计与扫描兜底 #

最后，建议做一次全面的代码审计，找出所有直接输出异常信息的代码块；也可以用静态代码扫描工具（比如SonarQube）检测这类违规代码，避免遗漏。修复后一定要测试这些特定URL的错误场景，确保敏感信息不再泄露。

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