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

最近在面试候选人时，我发现一个挺有意思的现象：很多开发者对SpringBoot的自动配置、启动流程、事务管理这些“硬核”知识点如数家珍，但当我问到“你的SpringBoot项目是如何预防XSS攻击的？”时，不少人会卡壳，或者只能说出“用过滤器过滤一下”这样模糊的答案。这其实暴露了一个问题：我们往往更关注框架本身的功能实现，而忽略了应用上线后最基本的安全防线。XSS（跨站脚本攻击）可不是什么冷门漏洞，它常年稳居OWASP Top 10榜单前列，攻击门槛低、危害大，轻则窃取用户会话Cookie，重则直接盗取用户资金、进行钓鱼诈骗。对于一个成熟的SpringBoot开发者来说，构建一个功能完备的应用只是第一步，为它穿上坚固的“防弹衣”才是真正体现工程素养的地方。

简单来说，XSS攻击就是攻击者将恶意的脚本代码（通常是JavaScript）注入到网页中，当其他用户浏览该页面时，嵌入的恶意脚本就会被执行。在SpringBoot构建的Web应用中，用户输入的任何地方——搜索框、评论框、个人资料编辑，甚至是URL参数——都可能成为攻击的入口。如果你的应用没有做任何防护，那么攻击者提交一段 <script>alert('你被攻击了')</script> 只是最温和的“打招呼”，更危险的是他们可以构造代码来窃取用户的登录凭证（ document.cookie ），或者将用户重定向到钓鱼网站。因此，在SpringBoot项目中系统地预防XSS，不是一道可做可不做的“附加题”，而是保障业务数据和用户隐私的“必答题”。接下来，我就结合自己多年的实战经验，从攻击原理到落地方案，为你拆解一套在SpringBoot中构建XSS防御体系的完整思路。

2. 核心思路：构建纵深防御体系，而非依赖单一方案

很多新手在应对XSS时，容易陷入一个误区：找到一个“银弹”方案，比如一个“万能”的过滤器，然后认为问题就解决了。在实际的攻防对抗中，这种单一维度的防御非常脆弱，攻击者总有办法找到你的防御盲点。我推崇的是 “纵深防御” 理念。这就像古代的城池，不仅有高大的外墙（第一道防线），还有瓮城、内城、护城河（第二、第三道防线）。在SpringBoot项目中，这意味着我们需要在数据流入、处理和流出的多个环节层层设防。

2.1 输入验证：守好第一道门

输入验证是防御的起点，其核心思想是 “白名单”优于“黑名单” 。不要试图去穷举所有可能的恶意字符（ < , > , script , onerror ...），这永远追不上攻击者的花样。相反，你应该根据每个字段的业务含义，定义它“应该是什么样子”。

例如，一个用户名字段，你可能只允许字母、数字和下划线，长度在2-20个字符之间。一个邮箱字段，必须符合RFC标准的邮箱格式。在SpringBoot中，我们可以非常方便地使用JSR 303/380 Bean Validation注解来实现这一点。

import javax.validation.constraints.*;

public class UserRegisterDTO {
    @NotBlank(message = "用户名不能为空")
    @Size(min = 2, max = 20, message = "用户名长度必须在2-20个字符之间")
    @Pattern(regexp = "^[a-zA-Z0-9_]+$", message = "用户名只能包含字母、数字和下划线")
    private String username;

    @NotBlank(message = "邮箱不能为空")
    @Email(message = "邮箱格式不正确")
    private String email;

    // ... 其他字段和Getter/Setter
}

在Controller层，通过 @Valid 注解即可触发校验：

@PostMapping("/register")
public ResponseEntity<?> register(@Valid @RequestBody UserRegisterDTO userDTO) {
    // 只有当参数通过校验后，才会执行到这里
    return ResponseEntity.ok(userService.register(userDTO));
}

实操心得 ：输入验证的重点在于“格式”和“长度”，它能过滤掉大量明显畸形、不符合业务逻辑的输入，减轻后续处理环节的压力。但它不能完全替代编码/转义，因为符合格式的输入里依然可能包含恶意字符（比如用户名里合法的下划线，在特定上下文中也可能被利用）。

2.2 输出编码/转义：最关键的核心防线

这是防御XSS最有效、最根本的手段。其原理是： 确保所有不可信的数据在输出到不同上下文时，都被转换为安全的表示形式 。关键在于“上下文”，在HTML里、在JavaScript里、在CSS里、在URL里，危险的字符和转义规则都是不同的。

  1. HTML上下文转义 ：这是最常见的场景。需要将 < , > , & , " , ' 等字符转换为对应的HTML实体（如 < -> &lt; , > -> &gt; ）。这样， <script> 在浏览器渲染时就会被显示为文本“ <script> ”，而不会被执行。
  2. JavaScript上下文转义 ：当需要将数据嵌入到 <script> 标签或事件处理器（如 onclick ）时，需要处理引号、反斜杠和换行符，通常使用JSON序列化是安全的方式。
  3. URL上下文转义 ：在将数据拼接到URL参数（href, src）时，需要使用URL编码。

手动处理这些规则既繁琐又容易出错。幸运的是，现代模板引擎都内置了自动转义功能。在SpringBoot中，Thymeleaf是默认且推荐的选择。

Thymeleaf的自动转义 ：在Thymeleaf中，使用 th:text 或 [[...]] 进行输出时，默认是开启HTML转义的。

<!-- 安全：userInput中的HTML标签会被转义 -->
<p th:text="${userInput}"></p>
<p>[[${userInput}]]</p>

<!-- 危险：使用th:utext或[(...)]会原样输出HTML，仅在完全信任内容时使用 -->
<p th:utext="${trustedHtmlContent}"></p>
<p>[(${trustedHtmlContent})]</p>

重要提示 ：除非你百分之百确定内容来源绝对安全（例如来自你自己系统的、经过严格审核的富文本），否则 永远不要使用 th:utext 或 [(...)] 。这是导致XSS漏洞最常见的原因之一。

2.3 内容安全策略：最后的浏览器端保险

CSP是一种由浏览器提供的、声明式的安全策略。它不直接处理数据，而是告诉浏览器：“我的页面只允许加载来自哪些地方的脚本、样式、图片等资源。” 即使攻击者成功注入了恶意脚本，如果该脚本的来源不在CSP允许的白名单内，浏览器也会拒绝执行。

在SpringBoot中，可以通过配置 HttpSecurity 来添加CSP头：

import org.springframework.context.annotation.Bean;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        // ... 其他安全配置
        .headers(headers -> headers
            .contentSecurityPolicy(csp -> csp
                .policyDirectives("default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://img.example.com;")
            )
        );
    return http.build();
}

上面的策略表示：默认只允许加载同源（ 'self' ）资源；脚本只允许来自同源和 https://trusted.cdn.com ；样式允许同源和内联样式（ 'unsafe-inline' ，必要时可放宽）；图片允许同源、data URL和 https://img.example.com 。

注意事项 ：配置CSP需要谨慎，过于严格的策略可能会阻断你站点正常的第三方资源（如统计代码、字体库、地图SDK）加载。建议先在“仅报告”模式（ Content-Security-Policy-Report-Only ）下运行，观察一段时间，根据浏览器报告调整策略，再正式启用。

3. 核心方案选型与落地实践

理解了纵深防御的思路后，我们来看看在SpringBoot中具体有哪些技术选型和落地步骤。我将从最常用的方案开始，逐步深入到更定制化的场景。

3.1 方案一：使用成熟的开源库进行全局过滤

对于大多数标准CRUD应用，使用一个经过社区验证的库来处理请求参数的全局过滤，是最快、最省心的方案。这里我推荐 OWASP Java Encoder 和 Jsoup 的组合。

OWASP Java Encoder 提供了针对不同上下文（HTML、JavaScript、CSS、URL）的编码器，API简单直接。 Jsoup 是一个HTML解析、清理库，除了提供白名单过滤功能，还能保证输出HTML的格式良好。

第一步：引入依赖 在你的 pom.xml 中添加：

<dependency>
    <groupId>org.owasp.encoder</groupId>
    <artifactId>encoder</artifactId>
    <version>1.3.1</version> <!-- 请使用最新版本 -->
</dependency>
<dependency>
    <groupId>org.jsoup</groupId>
    <artifactId>jsoup</artifactId>
    <version>1.17.2</version> <!-- 请使用最新版本 -->
</dependency>

第二步：创建全局过滤器（Servlet Filter） 这是方案的核心。过滤器会在请求到达Controller之前，对参数进行清理。

import org.owasp.encoder.Encode;
import org.jsoup.Jsoup;
import org.jsoup.safety.Safelist;
import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;

public class XssFilter implements Filter {

    // 定义一个宽松的白名单，允许基本的文本格式标签（如b, i, u），但拒绝所有脚本和样式
    private static final Safelist HTML_WHITELIST = Safelist.relaxed()
            .addTags("p", "br", "div", "span")
            .removeTags("script", "style", "iframe", "frame", "frameset", "object", "embed", "applet", "meta", "link");

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        // 包装请求，重写获取参数的方法
        XssHttpServletRequestWrapper wrappedRequest = new XssHttpServletRequestWrapper(httpRequest);
        chain.doFilter(wrappedRequest, response);
    }

    // 内部包装类
    private static 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[] cleanedValues = new String[values.length];
            for (int i = 0; i < values.length; i++) {
                cleanedValues[i] = cleanXss(values[i]);
            }
            return cleanedValues;
        }

        @Override
        public String getHeader(String name) {
            String value = super.getHeader(name);
            return cleanXss(value);
        }

        private String cleanXss(String value) {
            if (value == null || value.isEmpty()) {
                return value;
            }
            // 1. 使用Jsoup进行基于白名单的HTML过滤（适用于可能包含简单格式的字段，如商品描述）
            String cleanHtml = Jsoup.clean(value, HTML_WHITELIST);
            // 2. 对过滤后的结果再进行HTML实体编码（双重保险）
            // 注意：这里使用forHtml是为了输出到HTML正文上下文。如果是其他上下文，需选用对应编码器。
            return Encode.forHtml(cleanHtml);
        }
    }
}

第三步：注册过滤器 在SpringBoot配置类中注册这个过滤器，使其对所有请求生效。

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<XssFilter> xssFilterRegistration() {
        FilterRegistrationBean<XssFilter> registration = new FilterRegistrationBean<>();
        registration.setFilter(new XssFilter());
        registration.addUrlPatterns("/*"); // 过滤所有请求
        registration.setName("xssFilter");
        registration.setOrder(1); // 设置过滤器的执行顺序，数字越小优先级越高
        return registration;
    }
}

踩坑记录与技巧 ：

  1. 性能考量 ：过滤器会对每个请求的每个参数进行遍历和处理，在高并发场景下可能成为瓶颈。建议通过 addUrlPatterns 缩小过滤范围（如只过滤 /api/* ），或者对已知安全的接口（如健康检查 /actuator/health ）进行排除。
  2. 白名单配置 ： Safelist 的配置是门艺术。 Safelist.relaxed() 允许了非常多的标签，在生产中通常需要根据业务裁剪。例如，电商的商品详情页可能需要允许 <img> ，但评论框可能只需要 <p> 和 <br> 。务必根据最小权限原则配置。
  3. 编码上下文 ：上面的示例统一用了 Encode.forHtml() ，这适用于大多数输出到HTML body的场景。但如果你的数据最终要放入 <script> 标签内，则需要使用 Encode.forJavaScript() 。 务必根据数据最终的输出位置，选择正确的编码器 。

3.2 方案二：与Spring Validation和自定义注解结合

过滤器方案是全局的、粗粒度的。有时我们需要更细粒度的控制，比如“这个字段我需要保留一些HTML格式（如加粗），那个字段我需要完全纯文本”。这时，可以结合Spring的校验框架和自定义注解。

第一步：创建自定义注解 @XssSafe 

import javax.validation.Constraint;
import javax.validation.Payload;
import java.lang.annotation.*;

@Documented
@Constraint(validatedBy = XssValidator.class) // 指定校验器
@Target({ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
public @interface XssSafe {
    String message() default "输入内容包含不安全的脚本或HTML";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    // 可以增加属性，如SafeLevel level()，用于区分不同的过滤严格等级
}

第二步：实现校验器 XssValidator 

import org.jsoup.Jsoup;
import org.jsoup.safety.Safelist;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;

public class XssValidator implements ConstraintValidator<XssSafe, String> {

    private Safelist safelist;

    @Override
    public void initialize(XssSafe constraintAnnotation) {
        // 这里可以读取注解上的属性，动态创建不同严格级别的Safelist
        this.safelist = Safelist.none(); // 最严格级别：只保留文本，移除所有标签
        // this.safelist = Safelist.basicWithImages(); // 基础级别：允许基本文本格式和图片
    }

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (value == null || value.isEmpty()) {
            return true;
        }
        // 使用Jsoup清理
        String clean = Jsoup.clean(value, safelist);
        // 如果清理前后内容不一致，说明包含了不被允许的标签/属性，校验失败
        return clean.equals(value);
    }
}

第三步：在DTO上使用注解 

public class ArticleDTO {
    @NotBlank
    private String title;

    @XssSafe // 对简介进行严格的纯文本过滤
    private String summary;

    // 对于文章正文，我们可能需要允许更多的HTML标签（如加粗、斜体、列表）
    // 可以定义另一个注解 @RichTextSafe，其对应的Validator使用更宽松的Safelist
    @RichTextSafe
    private String content;
}

这样，在Controller中通过 @Valid 触发校验时，如果 summary 字段包含了任何HTML标签，校验就会失败，并返回我们在注解中定义的错误信息。

方案对比 ：方案一（过滤器）是“强制净化”，所有输入都会被处理。方案二（注解）是“声明式校验”，只有标记了注解的字段才会被检查，并且校验失败会阻止业务逻辑执行，更符合Spring的编程范式。 我个人的建议是两者结合使用 ：用全局过滤器做基础兜底，再用自定义注解对关键业务字段进行精确控制。

3.3 方案三：针对富文本编辑器的特殊处理

评论系统、博客后台、客服系统等场景常常需要富文本编辑器（如UEditor、WangEditor、TinyMCE）。用户需要提交包含复杂HTML格式（字体、颜色、图片、表格）的内容。对于这种场景， 完全禁止HTML是不现实的，但完全信任又是极度危险的 。处理富文本的核心是： 使用一个严格定义的白名单，只允许安全的标签和属性通过，并坚决过滤掉所有可能执行脚本的标签和属性。

这里 Jsoup的Safelist 再次成为利器。我们需要精心构造一个白名单。

import org.jsoup.Jsoup;
import org.jsoup.safety.Safelist;

public class RichTextXssCleaner {

    private static final Safelist RICH_TEXT_WHITELIST = Safelist.none()
            // 允许的标签
            .addTags(
                "p", "br", "div", "span", "h1", "h2", "h3", "h4", "h5", "h6",
                "b", "strong", "i", "em", "u", "strike", "sup", "sub",
                "ul", "ol", "li",
                "a", "img", "blockquote", "code", "pre", "hr",
                "table", "thead", "tbody", "tr", "th", "td"
            )
            // 为特定标签添加允许的属性
            .addAttributes("a", "href", "title", "target")
            .addAttributes("img", "src", "alt", "title", "width", "height")
            .addAttributes("table", "border", "cellpadding", "cellspacing")
            .addAttributes("th", "colspan", "rowspan")
            .addAttributes("td", "colspan", "rowspan")
            // 为所有标签添加通用的样式属性（谨慎开启）
            // .addAttributes(":all", "style", "class")
            // 对链接的href和图片的src进行协议过滤，只允许http/https
            .addProtocols("a", "href", "http", "https")
            .addProtocols("img", "src", "http", "https", "data") // data协议用于base64图片
            // 强制为所有外部链接添加 rel="noopener noreferrer"，防止钓鱼安全风险
            .addEnforcedAttribute("a", "rel", "nofollow noopener noreferrer");

    public static String clean(String html) {
        if (html == null || html.trim().isEmpty()) {
            return html;
        }
        return Jsoup.clean(html, RICH_TEXT_WHITELIST);
    }
}

关键点解析 ：

  • addTags : 只添加业务必需的标签。坚决不添加 script , style , iframe , object , embed , form , input , button 等。
  • addAttributes : 精确控制每个标签允许的属性。例如， <a> 标签只允许 href , title , target ，防止 onclick 等事件处理器。
  • addProtocols : 这是防止“伪协议XSS”的关键。例如， <a href=”javascript:alert(1)”> ，如果只检查标签和属性而不检查协议，依然危险。这里限制 href 只能以 http:// 或 https:// 开头。
  • addEnforcedAttribute : 强制添加安全属性。 nofollow 对SEO有益， noopener noreferrer 能有效防止通过 window.opener 对象进行的安全攻击。

血泪教训 ：我曾经遇到过一种高级攻击，攻击者利用 <img src=”x” onerror=”alert(1)”> 进行攻击。即使我们过滤了 onerror 属性，他还可以用 <img src=”x” style=”background-image: url(javascript:alert(1))”> 。因此，对于 style 属性，要么完全禁止（如上面的示例），要么必须使用一个非常严格的CSS解析器来验证其内容。在不确定的情况下， 禁止style和class属性是最安全的选择 。

4. 实战中的疑难杂症与排查技巧

即使按照上面的方案部署了防御，在实际运行中还是可能遇到各种奇怪的问题。下面是我总结的一些常见“坑点”和排查思路。

4.1 问题一：过滤器导致JSON请求体（@RequestBody）失效

这是最常见的问题。我们上面实现的 XssFilter ，重写的是 getParameter 、 getHeader 等方法，这些方法针对的是 application/x-www-form-urlencoded 或 multipart/form-data 格式的表单数据。而对于 application/json 格式的请求体，数据是通过 HttpServletRequest 的输入流（ getInputStream() ）读取的， getParameter 是拿不到数据的。

解决方案 ：需要重写 getInputStream() 方法，对流中的数据进行清洗。但要注意，流只能读取一次。我们可以使用Spring提供的 ContentCachingRequestWrapper 或者自己实现一个缓存请求体的Wrapper。

一个简化版的思路是，在过滤器中，对于JSON请求，先读取、解析、清洗请求体，然后再将清洗后的数据塞回一个新的输入流中。但这种方法对性能有影响，且处理起来较复杂。

更优雅的解决方案 ：将XSS清洗逻辑后置，放在Controller层参数绑定时，或者Service层处理业务数据之前。这正是 方案二（自定义注解） 的优势所在。对于JSON请求，我们完全可以在接收参数的DTO字段上使用 @XssSafe 注解，让校验器来负责清洗，完全避开过滤器处理请求体的难题。

4.2 问题二：与文件上传（MultipartFile）的冲突

当表单中包含文件上传时，请求类型是 multipart/form-data 。此时，如果过滤器或拦截器不当处理了 getParameter ，可能会导致Spring的 MultipartResolver 无法正确解析文件，从而拿不到 MultipartFile 对象。

排查与解决 ：

  1. 检查过滤器顺序 ：确保处理XSS的过滤器注册在Spring的 MultipartFilter 之后。在Spring Boot中，文件解析通常由 DispatcherServlet 处理。你可以通过设置 FilterRegistrationBean 的 setOrder() 方法来调整顺序。
  2. 条件过滤 ：在过滤器的 cleanXss 方法中，增加对请求类型的判断。如果是 multipart/form-data ，则跳过对请求体的处理（但请求头仍需处理），因为文件内容是二进制流，不应进行字符串清洗。 
    private String cleanXss(String value) {
    if (value == null) return null;
    String contentType = request.getContentType();
    if (contentType != null && contentType.startsWith("multipart/")) {
        // 对于文件上传请求，不对参数值进行清洗（或只进行极轻量的检查）
        // 因为文件内容本身不是文本，清洗会破坏它。
        // 但文件名（filename）参数仍需清洗！
        return value;
    }
    // ... 正常的清洗逻辑
}
  3. 专注清洗“文件名” ：攻击者可能通过构造恶意的文件名（如 test.jpg<script>alert(1)</script> ）进行攻击。因此，即使跳过文件内容，也务必对 filename 这个参数进行严格的清洗。

4.3 问题三：Ajax请求与特殊字符编码

前端通过Ajax（如jQuery.ajax, axios）提交数据时，如果包含了HTML实体字符（如 &lt; ），经过我们的过滤器或编码器转义后，可能会变成双重编码（如 &amp;lt; ），导致后端接收到的数据和预期不符。

根源分析 ：这通常是因为前端库和服务器对数据的编码/解码行为不一致。例如，jQuery在默认情况下会对数据进行一定的编码。

解决方案 ：

  1. 前后端约定 ：明确约定数据传输的格式。通常，建议前端提交原始数据（即用户输入的原样），由后端统一负责安全过滤和编码。
  2. 调整Ajax配置 ：如果你使用jQuery，可以设置 traditional: false （默认）并确保 contentType 为 application/x-www-form-urlencoded; charset=UTF-8 。对于复杂数据，直接使用 JSON.stringify() 提交JSON字符串，并在后端使用 @RequestBody 接收。
  3. 后端兼容处理 ：在后端的清洗逻辑中，可以考虑先进行一次解码（如 URLDecoder.decode ），然后再进行清洗和编码。但这需要谨慎，避免被“编码绕过”攻击（如攻击者提交 %3Cscript%3E ，解码后是 <script> ）。

一个实用的调试技巧 ：在开发阶段，在过滤器的 cleanXss 方法前后打印日志，对比原始值和清洗后的值。同时，使用浏览器开发者工具的“网络”选项卡，查看请求负载（Payload）的原始格式，确保你看到的就是前端实际发送的数据。

4.4 问题四：第三方组件和库引入的XSS风险

你的应用可能引入了富文本编辑器组件、图表库、Markdown解析器等第三方前端库。这些库本身也可能存在XSS漏洞，或者其使用方式不当会引入风险。

防御策略 ：

  1. 保持更新 ：定期更新所有第三方库到最新稳定版，关注其安全公告。
  2. 沙箱隔离 ：对于需要渲染不可完全信任的第三方内容（如用户提交的Markdown、通过iframe嵌入的外部页面），尽可能使用沙箱（sandbox）属性。HTML5的 <iframe sandbox=”allow-scripts”> 可以严格限制内嵌页面的能力。
  3. CSP加固 ：如前所述，配置严格的CSP是防御第三方资源被篡改或引入恶意代码的最后一道有效屏障。通过 script-src 指令限制脚本只能从可信源加载。

5. 构建持续的安全防护与测试体系

安全不是一劳永逸的配置，而是一个持续的过程。除了在开发阶段实施上述防护措施，还需要建立配套的流程和习惯。

5.1 将安全扫描纳入CI/CD流水线

在项目的持续集成/持续部署流水线中，加入自动化的安全扫描工具。对于Java项目，可以集成 OWASP Dependency-Check 来检查项目依赖库中已知的漏洞（包括可能导致XSS的库）。还可以使用 SonarQube 配合相关的安全规则集，对代码进行静态分析，找出潜在的不安全编码模式。

5.2 定期进行人工安全审计与渗透测试

自动化工具能发现常见问题，但无法替代人脑的创造性思维。建议定期（如每季度或每次大版本发布前）进行人工代码审计，重点审查：

  • 所有用户输入点（Controller接口、API参数）。
  • 所有动态输出到页面的地方（模板文件、通过JavaScript动态拼接的HTML）。
  • 富文本处理逻辑。
  • 过滤器和拦截器的配置是否正确，有无被绕过的可能。

如果条件允许，可以邀请公司内部的安全团队或外部的白帽子进行渗透测试，他们往往会从攻击者的视角发现你意想不到的漏洞。

5.3 建立安全编码规范与培训

在团队内部推行安全编码规范，并将其作为代码审查（Code Review）的必查项。规范中应明确：

  • 所有外部输入都必须视为不可信的。
  • 输出到HTML必须进行上下文相关的编码。
  • 禁止使用 innerHTML , document.write , eval() 等危险的JavaScript函数，除非数据经过严格的安全处理。
  • 使用安全的DOM API，如 textContent 代替 innerHTML ， addEventListener 代替内联事件处理器。

对新加入团队的成员进行基础的安全意识培训，让他们从写第一行代码开始就养成安全的习惯。

最后，我想分享一个个人体会：防御XSS，技术方案固然重要，但更重要的是建立起一种“安全第一”的思维模式。每次处理用户输入时，心里都要拉响警报；每次输出数据到前端时，都要下意识地问自己一句：“这里我编码了吗？” 把这种条件反射变成开发习惯，才是构建坚固应用安全防线的根本。在SpringBoot这个强大的框架里，我们有丰富的工具和生态来简化安全工作，但工具永远替代不了人的意识和责任心。希望这篇长文能帮你和你的团队，在下一个SpringBoot项目中，构建起一道令攻击者望而却步的XSS防线。

Logo
亚马逊云科技技术品牌专区

更多推荐

Kiro Editor 开发实战：使用 Cargo 构建、测试与性能优化指南

欢迎来到这篇终极指南，我们将深入探索如何使用Rust构建高性能的终端文本编辑器Kiro Editor。无论你是Rust新手还是经验丰富的开发者，这篇完整教程将带你了解如何利用Cargo工具链进行高效的开发、测试和性能优化，打造一款快速、轻量且功能强大的UTF-8文本编辑器。## 什么是Kiro Editor？Kiro Editor是一款使用Rust编写的极简终端文本编辑器，它最初是著名编辑

avatar 亚马逊云科技技术品牌专区

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

avatar 亚马逊云科技技术品牌专区