Spring Boot中结合ESAPI与正则过滤XSS注入，实现方式是否正确？

一、同时使用ESAPI canonicalize与自定义正则的安全性问题 #

• 冗余与逻辑顺序风险：ESAPI的canonicalize是将各种编码格式的输入还原为原始形式，而你的正则是直接匹配恶意字符串。如果先执行正则过滤再做规范化，编码后的恶意内容（如%3Cscript%3E）会绕过正则，经canonicalize还原后成为有效攻击代码；即便先做规范化再正则，你的正则覆盖范围也存在明显漏洞：
  • 未覆盖onclick、onmouseover等高危事件属性
  • 无法处理HTML实体编码的恶意前缀（如javascript:）
  • 非贪婪匹配(.*?)在嵌套或复杂构造下可能失效
• 过度过滤破坏合法输入：用户正常输入的技术文档、代码片段（含<script>等字样）会被无差别过滤，影响业务体验。

二、ESAPI的正确用法 #

不要仅依赖canonicalize，应结合ESAPI的核心编码能力：

• 按上下文输出编码：这是XSS防护的核心原则——输出到HTML页面用ESAPI.encoder().encodeForHTML(userInput)，输出到JS脚本用encodeForJavaScript，输出到URL用encodeForURL，从输出端阻断攻击。
• 输入验证配合：用ESAPI的Validator组件做输入格式校验，比如限定输入为字母数字、邮箱或手机号格式，从源头减少恶意输入的可能性。

三、替代方案 #

Spring生态原生方案 #

• Spring Security XSS过滤器：配置HttpSecurity时添加自定义XSS过滤器，或使用XssRequestWrapper对请求参数进行预处理。
• Thymeleaf自动编码：若使用Thymeleaf，默认会对变量输出做HTML编码，避免使用th:utext（无编码输出）即可自动防护大部分HTML上下文的XSS。

轻量专业库 #

• OWASP Java Encoder：专注于输出编码的轻量库，比ESAPI更精简，适合不需要全量ESAPI功能的场景。
• 全局参数处理过滤器：实现Filter接口，在请求进入控制器前对所有参数进行规范化+编码，但需区分JSON、表单等不同参数类型的处理逻辑。

核心防护原则 #

优先采用输出编码而非输入过滤，输入过滤仅作为补充手段——输入的合法场景多样，正则或过滤规则无法覆盖所有浏览器解析的特殊情况，输出编码才是更可靠的防护方式。

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