Spring Boot应用XSS防御实战：从过滤器到JSON反序列化的纵深防护体系
1. 项目概述：为什么Spring Boot应用必须构建多层面XSS防御体系
在Web应用开发中，XSS（跨站脚本攻击）就像是一个潜伏在用户输入框里的“隐形黑客”。它不像SQL注入那样直接攻击数据库，而是利用应用对用户输入数据的信任，将恶意脚本“夹带”进网页，在受害者的浏览器里执行。我见过太多项目，前端做了校验，后端也做了简单的参数过滤，但攻击者一个大小写变换、一个编码绕过，防御就形同虚设。Spring Boot以其快速开发著称，但默认的安全配置并不足以应对复杂的XSS攻击变种。一个留言板系统，如果用户输入<script>alert('你的Cookie是：'+document.cookie)</script>而未被处理，那么所有访问该页面的用户都可能面临会话劫持的风险。因此，构建一个从数据入口到数据出口、覆盖不同传参方式的多层面防御体系，不是“锦上添花”，而是保障业务数据安全和用户隐私的“生命线”。这篇文章，我将结合我处理过的真实案例，拆解在Spring Boot中实现有效XSS防御的详细步骤、核心原理以及那些容易踩坑的细节。
2. 核心思路与架构设计：构建纵深防御网络
单点防御在安全领域是极其危险的。我的思路是构建一个“纵深防御”体系，针对请求生命周期的不同阶段和不同数据格式，部署相应的防御策略。这就像给城堡设置多重关卡：护城河、城墙、内城守卫，每一层都有其独特的防御重点。
2.1 防御层面的划分与协同
一个完整的Spring Boot Web请求，数据流入和流出主要有以下几个关键节点，我们的防御体系需要覆盖它们：
- HTTP请求入口（过滤器层）：这是第一道，也是最重要的防线。所有请求最先到达这里。我们需要在此对原始请求数据进行清洗和转义。重点处理两种主流数据格式：
application/x-www-form-urlencoded(表单键值对)：通过request.getParameter()获取。application/json：通过request.getInputStream()获取的请求体。
- 业务逻辑层（序列化/反序列化层）：过滤器是第一道通用防线，但有些场景需要更精细的控制。例如，我们可能希望存入数据库的是原始HTML（如富文本编辑器内容），但输出时要转义。这时就需要在Jackson处理JSON时介入。
- 视图渲染层（模板引擎层）：这是最后一道输出防线。即使数据在入库时是“干净”的，或者在某个环节被错误地还原，在渲染到HTML页面时，模板引擎应能自动对动态内容进行HTML转义。Thymeleaf和FreeMarker默认是开启的，但需要确认。
- 响应头加固：通过设置HTTP响应头，如
Content-Security-Policy (CSP)，从浏览器策略层面限制脚本执行，即使有恶意脚本注入，浏览器也会阻止其执行。这是“兜底”的缓解措施。
本次实战，我们将聚焦于最核心、最常用的过滤器层防御，并简要探讨序列化层的补充方案。视图层和CSP作为最佳实践提示。
2.2 技术方案选型：为什么选择自定义过滤器？
常见的Spring Boot防XSS方案有几种：使用现成的安全框架（如Spring Security的XssProtectionHeaderWriter，但功能较弱）、引入第三方库（如lucy-xss-servlet-filter）、或自己实现过滤器。我选择自定义过滤器，基于以下几点考量：
- 可控性最强：第三方库可能更新不及时或过滤规则不符合业务需求（比如过于严格，过滤了富文本编辑器需要的合法标签）。自己实现，规则完全自己定。
- 性能透明：可以精确控制过滤逻辑的复杂度，避免引入不必要的性能开销。所有代码都在自己掌控中，便于优化。
- 与业务集成度高：可以方便地配置排除列表（如某些接收HTML的接口）、根据请求方法（GET/POST）灵活处理。
- 学习价值：亲手实现一遍，对Servlet规范、请求/响应包装器、数据流处理会有更深刻的理解，这是直接用工具库无法获得的。
我们的自定义过滤器核心是继承HttpServletRequestWrapper，包装原始的HttpServletRequest。在包装器中，重写getParameter,getParameterValues,getHeader,getInputStream等方法，在这些方法返回数据给应用之前，对数据进行清洗或转义。
关键决策点：转义(Encoding) vs 过滤(Filtering)这是两个核心策略。转义是将危险字符（如
<,>,&,",'）替换为对应的HTML实体（如<,>,&,",'）。这样，<script>在浏览器中会被显示为文本“