1. 项目概述：为什么XSS是Java开发者绕不开的“坑”

干了这么多年Java开发，从早期的JSP、Struts到现在的Spring Boot全家桶，项目做了不少，安全漏洞也踩过不少。其中，XSS（跨站脚本攻击）绝对是一个“老演员”，几乎在每次代码审计或渗透测试中都能看到它的身影。它不像SQL注入那样直接“爆库”那么显眼，但危害一点不小——轻则弹个烦人的广告窗口，重则悄无声息地盗走用户的登录Cookie，进行会话劫持，甚至以用户身份执行敏感操作。

这个项目标题“Java代码中的XSS攻击隐患：前端与后端的安全防护措施”点出了两个核心：一是隐患存在于我们写的Java代码里，无论是后端逻辑还是前端渲染；二是防护必须是立体的，需要前后端协同作战。很多团队容易陷入一个误区：认为用了Spring Security或者在前端用Vue/React就万事大吉了。实际上，框架提供了工具，但“枪”怎么用，会不会走火，完全取决于开发者。我见过太多因为一个 innerHTML 的误用，或者一次 HttpServletResponse 的直接输出，就导致整个安全防线形同虚设的案例。接下来，我就结合自己踩过的坑和修复过的漏洞，把XSS在Java Web应用中的来龙去脉、怎么防、怎么查，掰开揉碎了讲清楚。

2. XSS攻击原理与Java应用中的典型风险场景

要防御，首先得知道敌人怎么进攻。XSS的本质是“让浏览器执行了本不该执行的脚本”。在Java Web应用里，数据流通常是从用户输入开始，经过后端Java处理，存入数据库，再取出渲染到前端页面。攻击者就像在数据流的管道上凿洞，注入恶意代码。

2.1 三种XSS攻击类型在Java项目中的体现

存储型XSS（最危险） ：攻击者提交的恶意脚本被你的Java后端程序接收后，未经充分处理就存进了数据库（比如MySQL、PostgreSQL）。之后，每当其他用户访问展示该数据的页面时（例如论坛帖子、商品评论、用户昵称），恶意脚本就会从服务器“存储”的数据中被读取并执行。

  • Java场景 ：一个典型的Spring MVC控制器，直接使用 @RequestParam 或 @RequestBody 接收评论内容，然后通过JPA/Hibernate的 Repository.save() 存入数据库。在Thymeleaf或JSP页面上，直接用 ${comment.content} 输出。如果中间没有转义，攻击就成功了。

反射型XSS（最常见） ：恶意脚本作为请求参数（如URL中的查询字符串、表单数据）“反射”回给用户的页面。它不存储，通常需要诱骗用户点击一个精心构造的链接。

  • Java场景 ：一个搜索功能， /search?keyword=<script>alert('xss')</script> 。后端Controller用 String keyword = request.getParameter("keyword"); 获取后，未做处理就直接拼接进HTML响应里，如 out.println("您搜索的是: " + keyword); 。

DOM型XSS（最隐蔽） ：整个攻击过程发生在客户端浏览器，不涉及后端响应。恶意脚本通过修改页面的DOM结构来实施。

  • Java场景 ：虽然根源在前端JavaScript，但后端可能“无意助攻”。比如，一个Java后端API返回了一段JSON数据，其中某个字段包含了未转义的HTML片段。前端JavaScript用 eval() 、 innerHTML 或 document.write() 等方式处理了这个数据，导致了脚本执行。

2.2 Java后端常见风险代码模式

很多漏洞都源于一些看似无害的“快捷写法”。

  1. JSP中的直接表达式输出 ：这是历史遗留的重灾区。

    <%-- 高危！直接输出用户输入 --%>
<div>欢迎您，<%= request.getParameter("username") %></div>

    即使到了现在，在一些老项目或特定场景下，这种写法依然存在。

  2. Spring MVC的 @ResponseBody 与JSON注入 ：很多人以为返回JSON就安全了，其实不然。如果JSON值被前端直接用于 innerHTML 或 eval() ，同样危险。

    @RestController
public class UserController {
    @GetMapping("/userInfo")
    public User getUserInfo() {
        User user = userService.findUser();
        // 假设user.getNickname()来自用户输入且未清洗
        // 前端如果这样用：document.getElementById('name').innerHTML = data.nickname;
        // 漏洞就产生了
        return user;
    }
}

  3. 错误信息回显 ：在全局异常处理器或登录失败处理中，直接将用户输入或异常信息返回给页面。

    @ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(Exception.class)
    public String handleError(HttpServletRequest request, Exception ex) {
        request.setAttribute("errorMessage", ex.getMessage()); // ex.getMessage()可能包含攻击载荷
        return "error";
    }
}

2.3 前端风险：模板与框架的“安全假象”

现代前端框架如Vue、React确实在默认情况下提供了基础的HTML转义，但这绝不是“免死金牌”。

  • Vue中的 v-html 指令 ：这是Vue官方明确指出的“危险操作”。当你不得不使用它时，就意味着你必须百分百信任该内容，或者已经进行了后端转义。 
    <template>
  <!-- 安全，默认插值会转义 -->
  <div>{{ userProvidedContent }}</div>
  <!-- 高危！除非content是可信的、已转义的HTML -->
  <div v-html="userProvidedContent"></div>
</template>
  • React的 dangerouslySetInnerHTML ：看名字就知道危险。它的存在是为了处理极端情况，日常业务开发中应极力避免。
  • jQuery时代的遗留问题 ：大量存量项目还在使用jQuery， $('#div').html(userInput) 是XSS的经典入口。

实操心得 ：不要依赖框架的默认安全机制而放松警惕。安全是一个链条，最薄弱的一环决定了整体强度。每次当你打算把一段字符串“画”到页面上时，都要条件反射地问自己：它的来源可信吗？我转义了吗？

3. 后端Java的纵深防护体系

后端的防护核心是 “输入验证、输出编码” 八字方针。但具体怎么做，有很多细节。

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

输入验证的目标是确保数据符合业务规则，拒绝非法格式。它不是防御XSS的唯一手段，但是重要屏障。

策略一：使用JSR 380 (Bean Validation 2.0) 进行声明式验证 这是Spring Boot项目中我最推荐的方式。在DTO或实体类的字段上使用注解，清晰又强大。

import javax.validation.constraints.NotBlank;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;

public class CommentDTO {
    @NotBlank(message = "内容不能为空")
    @Size(max = 500, message = "内容长度不能超过500字符")
    @Pattern(regexp = "^[\\s\\S]*$", message = "内容包含非法字符") // 这是一个非常宽松的例子，实际应根据业务收紧
    private String content;

    // 更严格的例子：只允许中英文、数字和常见标点
    // @Pattern(regexp = "^[\\u4e00-\\u9fa5a-zA-Z0-9\\s\\p{P}]*$", message = "只能包含中英文、数字和标点")
    private String nickname;
}

在Controller中，使用 @Valid 注解触发验证：

@PostMapping("/comment")
public ResponseEntity<?> createComment(@Valid @RequestBody CommentDTO commentDTO, BindingResult result) {
    if (result.hasErrors()) {
        // 返回验证错误信息，注意错误信息本身也要防范XSS！
        return ResponseEntity.badRequest().body("参数校验失败");
    }
    // ... 业务逻辑
}

注意事项 ：正则表达式验证是一把双刃剑。过于严格可能影响用户体验（比如不允许任何HTML标签，但业务可能需要富文本）。对于富文本，应该采用“白名单”过滤策略，而不是简单的正则黑名单。

策略二：在Service层进行业务逻辑验证 有些验证无法通过注解表达，需要在服务层进行。

@Service
public class CommentService {
    public void saveComment(Comment comment) {
        // 检查是否包含明显的脚本标签（作为补充，非主要手段）
        if (containsMaliciousScript(comment.getContent())) {
            throw new BusinessException("内容包含不安全代码");
        }
        // 更常见的做法是调用HTML过滤器
        String safeContent = htmlFilter.filter(comment.getContent());
        comment.setContent(safeContent);
        commentRepository.save(comment);
    }
    // 一个简单的示例方法，实际应用需要更复杂的检测
    private boolean containsMaliciousScript(String input) {
        String lowerInput = input.toLowerCase();
        return lowerInput.contains("<script>") || lowerInput.contains("javascript:");
    }
}

3.2 输出编码：确保数据安全落地

无论输入验证多严格，输出编码都是 必须 的最后防线。原则是：数据在哪个上下文中使用，就用哪种编码方式。

1. HTML内容编码（最常用） 将 < , > , & , " , ' 等字符转换为对应的HTML实体（如 < , > ）。

  • 使用库 ：不要自己造轮子。推荐使用OWASP Java Encoder或Apache Commons Text。 
    <!-- Maven 依赖 - OWASP Java Encoder -->
<dependency>
    <groupId>org.owasp.encoder</groupId>
    <artifactId>encoder</artifactId>
    <version>1.3.1</version>
</dependency>

    import org.owasp.encoder.Encode;
// 在JSP或模板中，或者构造HTML字符串时使用
String safeOutput = Encode.forHtmlContent(userInput);
// 用于HTML属性
String safeAttr = Encode.forHtmlAttribute(userInput);
  • 在模板引擎中 ：
    • Thymeleaf ：默认情况下， th:text 或 [[...]] 会自动进行HTML转义。这是安全的。只有当你明确使用 th:utext 或 [(...)] 时，才需要确保内容已安全。 
      <!-- 安全，自动转义 -->
<div th:text="${userContent}"></div>
<div>[[${userContent}]]</div>
<!-- 危险！需要确保userContent是安全的HTML -->
<div th:utext="${trustedHtmlContent}"></div>
    • FreeMarker ：同样， ${userContent} 默认会转义。使用 ${userContent?no_esc} 或 <#escape> 指令时需要格外小心。
    • JSP ：使用JSTL的 <c:out> 标签，它默认转义。 切忌使用 ${} EL表达式直接输出不可信数据 。 
      <!-- 安全 -->
<c:out value="${userInput}" />
<!-- 高危！ -->
${userInput}

2. JavaScript上下文编码 当需要将Java变量嵌入到 <script> 标签中时，情况变得复杂。简单的HTML转义在这里无效。

<script>
    // 错误！如果userInput是 `"; alert('xss'); //`，就会闭合字符串执行脚本。
    var username = '<%= request.getParameter("name") %>';
    // 正确做法：使用专门的JavaScript编码
    var username = '<%= Encode.forJavaScriptBlock(request.getParameter("name")) %>';
</script>

在JSON API中，这个问题由JSON序列化库（如Jackson）解决。Jackson默认会对字符串值进行适当的转义。但关键是要确保输出的是 纯JSON ，而不是拼接的字符串。

@RestController
public class ApiController {
    @GetMapping("/data")
    public Map<String, Object> getData() {
        Map<String, Object> map = new HashMap<>();
        map.put("key", userInput); // Jackson序列化时会转义字符串中的特殊字符
        return map; // 返回对象，Spring Boot会用Jackson转换为JSON
    }
    // 危险！手动拼接JSON
    @GetMapping("/badData")
    public String getBadData() {
        return "{\"name\": \"" + userInput + "\"}"; // 如果userInput包含引号或斜杠，JSON结构会被破坏，可能引发XSS。
    }
}

3. URL参数编码 当用户输入需要作为URL的一部分时（比如重定向参数），必须进行URL编码。

import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

String redirectUrl = "/profile?username=" + URLEncoder.encode(userInput, StandardCharsets.UTF_8.toString());
// 更好的方式是使用UriComponentsBuilder (Spring)
UriComponentsBuilder.fromPath("/profile").queryParam("username", userInput).build().toUriString();

3.3 设置安全相关的HTTP响应头

这是另一道重要的防线，可以指示浏览器提供额外的保护。

  • Content-Security-Policy (CSP) ：这是对抗XSS的终极武器之一。它告诉浏览器只允许加载和执行来自特定来源的脚本、样式等资源。即使攻击者成功注入了脚本，如果来源不在白名单内，浏览器也不会执行。

    // 使用Spring Security配置CSP
@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .headers()
                .contentSecurityPolicy("default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline';");
                // 解释：默认只允许同源资源；脚本只允许同源和指定的CDN；样式允许同源和内联（某些UI框架需要）。
    }
}

    踩坑记录 ：刚开始配置CSP时非常痛苦，因为会阻断很多第三方资源（如统计代码、字体、地图API）。建议在开发环境先设置为 Content-Security-Policy-Report-Only 模式，只报告违规不阻断，根据报告逐步完善策略。

  • X-XSS-Protection ：为旧版IE和Chrome提供基本的反射型XSS过滤（已逐渐被CSP取代）。

  • X-Content-Type-Options: nosniff ：阻止浏览器MIME类型嗅探，降低某些基于文件上传的XSS风险。

  • HttpOnly Cookie ：在设置会话Cookie时，务必加上 HttpOnly 标志，这样JavaScript就无法通过 document.cookie 读取它，可以有效缓解Cookie窃取。

    // 在Spring Security或Servlet中设置
Cookie cookie = new Cookie("JSESSIONID", sessionId);
cookie.setHttpOnly(true);
cookie.setSecure(true); // 仅限HTTPS传输
response.addCookie(cookie);

4. 前端协同防护与安全编码实践

后端做了层层防护，前端也不能掉链子。前端是数据最终展示和执行的地方，这里的疏忽会让后端的所有努力前功尽弃。

4.1 安全的数据绑定与DOM操作

核心原则：分清“文本”和“HTML” 。把用户数据当作文本（text）处理是默认的安全姿势，只有在你明确知道它是安全的HTML时，才当作HTML处理。

  • 原生JavaScript ：

    // 危险！
element.innerHTML = userData;
// 安全（用于纯文本）
element.textContent = userData;
// 如果必须设置HTML，且内容可信/已过滤
element.innerHTML = trustedHtmlString;

  • Vue.js ：

    <template>
  <!-- 安全：文本插值 -->
  <span>{{ message }}</span>
  <!-- 危险：输出原始HTML -->
  <span v-html="rawHtml"></span> <!-- 确保rawHtml是后端已清洗或完全可信的 -->
</template>

  • React ：

    function MyComponent({ userContent }) {
  // 安全：默认转义
  return <div>{userContent}</div>;
  // 危险：设置内部HTML
  return <div dangerouslySetInnerHTML={{__html: userContent}} />;
}

4.2 安全的第三方库与API调用

  • 避免使用 eval() 和 new Function() ：这两个函数会直接执行字符串形式的代码，是巨大的安全漏洞。99.9%的场景都有更安全的替代方案（如 JSON.parse ）。
  • 谨慎处理 setTimeout / setInterval 的第一个参数 ：不要将用户输入直接传入。 
    // 危险！
setTimeout(userInput, 1000);
// 安全
setTimeout(function() { /* 写死的代码 */ }, 1000);
  • 净化URL ：在将用户输入设置为 <a> 标签的 href 或 <img> 的 src 前，要验证协议。防止 javascript: 伪协议攻击。 
    let userLink = userInput;
if (!userLink.startsWith('http://') && !userLink.startsWith('https://')) {
    userLink = 'about:blank'; // 或进行其他处理
}
aTag.href = userLink;

4.3 富文本编辑器的安全处理

这是XSS防御中最复杂的场景之一。业务需要富文本（如博客编辑器、客服系统），但又要防止恶意代码。

策略：白名单过滤（Sanitize） 使用成熟的库来过滤富文本HTML，只允许安全的标签和属性通过。

  • Java后端过滤 ：可以使用 OWASP Java HTML Sanitizer 。 
    <dependency>
    <groupId>com.googlecode.owasp-java-html-sanitizer</groupId>
    <artifactId>owasp-java-html-sanitizer</artifactId>
    <version>20220608.1</version>
</dependency>

    import org.owasp.html.PolicyFactory;
import org.owasp.html.Sanitizers;
public class HtmlSanitizerUtil {
    private static final PolicyFactory POLICY = Sanitizers.FORMATTING
            .and(Sanitizers.BLOCKS)
            .and(Sanitizers.IMAGES)
            .and(Sanitizers.LINKS)
            .and(Sanitizers.STYLES); // 定义允许的白名单策略
    public static String sanitize(String dirtyHtml) {
        return dirtyHtml == null ? null : POLICY.sanitize(dirtyHtml);
    }
}
// 使用
String safeHtml = HtmlSanitizerUtil.sanitize(richTextInput);
  • 前端过滤 ：可以使用 DOMPurify 。 
    import DOMPurify from 'dompurify';
const cleanHtml = DOMPurify.sanitize(dirtyHtml, {
    ALLOWED_TAGS: ['p', 'b', 'i', 'em', 'strong', 'a', 'img'], // 自定义白名单
    ALLOWED_ATTR: ['href', 'src', 'alt']
});
element.innerHTML = cleanHtml;

    最佳实践 ：建议在 后端进行最终的、强制的过滤 。前端过滤可以提高用户体验（实时预览），但必须后端兜底，因为攻击者可以绕过前端直接调用API。

5. 全链路防护策略与开发流程嵌入

单点防护不够，我们需要把安全思维嵌入到整个开发和运维流程中。

5.1 安全开发生命周期（SDL）实践

  1. 需求与设计阶段 ：识别涉及用户输入输出的功能点，明确安全要求。例如，在PRD或设计文档中标注“此字段需进行XSS过滤”。
  2. 编码阶段 ：
    • 制定编码规范 ：在团队规范中明确禁止 innerHTML 、 v-html 、 dangerouslySetInnerHTML 的直接使用，必须经过安全评审。
    • 使用安全组件 ：封装安全的输出组件，例如一个 <SafeText> 组件，强制进行转义。
    • 代码审查 ：将XSS漏洞检查作为代码审查的必选项。重点关注数据流：从 Controller 入参，到 Service 处理，再到 Repository 存储，最后到模板或API输出。
  3. 测试阶段 ：
    • 自动化扫描 ：集成SAST（静态应用安全测试）工具到CI/CD流水线，如SonarQube、Checkmarx，自动扫描代码中的潜在漏洞。
    • DAST动态扫描 ：使用OWASP ZAP、Burp Suite等工具对运行中的应用进行渗透测试。
    • 手动测试 ：构造常见的XSS测试载荷，如 <script>alert(1)</script> 、 <img src=x onerror=alert(1)> 、 javascript:alert(1) ，在输入框、URL参数等处尝试。
  4. 部署与运维阶段 ：
    • 确保WAF（Web应用防火墙）规则开启并更新，能拦截常见的XSS攻击模式。
    • 监控日志，对异常的、包含大量特殊字符的请求进行告警。

5.2 构建可复用的安全工具类

在项目中建立安全工具类，统一处理编码和过滤，避免散落的重复代码。

@Component
public class SecurityUtil {
    private static final PolicyFactory HTML_SANITIZER = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS).and(Sanitizers.IMAGES).and(Sanitizers.LINKS);
    /**
     * 对用于HTML正文的内容进行编码
     */
    public static String encodeForHtml(String input) {
        return input == null ? "" : Encode.forHtmlContent(input);
    }
    /**
     * 对用于HTML属性的内容进行编码
     */
    public static String encodeForHtmlAttr(String input) {
        return input == null ? "" : Encode.forHtmlAttribute(input);
    }
    /**
     * 富文本HTML过滤（白名单）
     */
    public static String sanitizeRichText(String dirtyHtml) {
        return dirtyHtml == null ? null : HTML_SANITIZER.sanitize(dirtyHtml);
    }
    /**
     * 简单的XSS敏感词检测（辅助，不能替代编码）
     */
    public static boolean containsXssIndicator(String input) {
        if (input == null) return false;
        String lower = input.toLowerCase();
        // 这是一个简单示例，实际需要更复杂的模式匹配
        return lower.contains("<script") || lower.contains("javascript:") || lower.contains("onerror=") || lower.contains("onload=");
    }
}

5.3 常见问题排查清单（Checklist）

当遇到疑似XSS漏洞或进行安全审计时，可以按此清单排查：

排查点 安全做法 风险做法
后端接收参数 使用 @Valid 验证DTO；在Service层进行业务逻辑校验。 直接使用 HttpServletRequest.getParameter() 后不做任何处理。
后端输出到HTML 模板引擎默认转义（Thymeleaf th:text , FreeMarker ${} ）；或手动调用 Encode.forHtmlContent() 。 JSP中使用 <%= %> ；任何地方直接字符串拼接HTML。
后端输出到JSON 使用Jackson等库序列化对象返回。 手动拼接JSON字符串。
后端重定向 使用 UriComponentsBuilder 或对参数进行URL编码。 直接拼接URL： "redirect:/page?name=" + input 。
前端文本展示 使用 textContent , {{ }} (Vue/React)， th:text 。 使用 innerHTML , v-html , dangerouslySetInnerHTML 。
前端设置链接/属性 检查协议（ http/https ），对动态属性值进行编码。 直接将用户输入赋给 href 、 src 、 action 。
富文本处理 后端使用HTML Sanitizer进行白名单过滤。 直接存储和展示用户提交的HTML。
Cookie 设置 HttpOnly 和 Secure 标志。 使用默认设置。
HTTP响应头 配置 Content-Security-Policy 。 无CSP或配置过于宽松（如 unsafe-inline ）。

6. 进阶：应对高级与混淆的XSS攻击

基础的防御措施能挡住大部分自动化扫描和初级攻击，但面对有经验的黑客，还需要更深入的理解。

6.1 编码上下文错误导致的绕过

这是最常见的防御绕过原因。在HTML属性里用了HTML实体编码，但属性本身是被 onclick 等事件处理器解析的，它需要的是JavaScript编码。

<!-- 假设后端对input进行了HTML编码，输出为 <img src=x onerror=alert(1)> -->
<div title="<img src=x onerror=alert(1)>"></div>
<!-- 这样是安全的，因为title属性里的<>被转义了。 -->

<!-- 但是，如果这个值被放到了事件处理器里 -->
<button onclick="confirm('{{userInput}}')">点击</button>
<!-- 假设userInput是 ');alert(1);// -->
<!-- 经过HTML编码后变成 &#39;);alert(1);// -->
<!-- 最终渲染为： -->
<button onclick="confirm('&#39;);alert(1);//')">点击</button>
<!-- 浏览器解析时，&#39;会被解码回单引号，从而闭合字符串，执行alert。 -->

解决方案 ：在动态构造JavaScript代码时，必须使用 JavaScript编码 （ Encode.forJavaScriptBlock 或 Encode.forJavaScriptAttribute ），而不是HTML编码。

6.2 基于SVG/MathML等载体的XSS

现代浏览器支持SVG内联。SVG本身是XML，可以包含 <script> 标签。

<!-- 如果允许用户上传SVG图片并直接内联展示 -->
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)">

解决方案 ：对用户上传的SVG、XML文件进行严格的解析和净化，或者禁止直接内联展示用户上传的SVG，将其作为普通图片文件处理（通过 <img> 标签的src引用，浏览器不会执行其中的脚本）。

6.3 DOM型XSS的深度排查

DOM型XSS的源头可能很深，比如来自第三方JavaScript库对 location.hash 、 document.referrer 或 postMessage 数据的处理。 排查方法 ：

  1. 搜索源代码中所有可能接收外部输入并操作DOM的 sink （接收点），如：
    • innerHTML , outerHTML , document.write()
    • eval() , setTimeout(string) , setInterval(string)
    • location.href , location.assign() (如果URL部分可控)
    • jQuery 的 html() , append() , $()
  2. 逆向追踪这些 sink 的数据来源（ source ），如：
    • location.search , location.hash
    • document.cookie
    • window.name
    • postMessage 事件数据
    • WebSocket 消息
  3. 检查从 source 到 sink 的路径上，是否有进行正确的编码或验证。

6.4 使用CSP对抗未知漏洞

即使存在未知的XSS漏洞，一个严格的CSP也能极大限制其危害。例如，禁止内联脚本执行( 'unsafe-inline' )，禁止 eval() ( 'unsafe-eval' )，那么即使脚本被注入，也无法执行。

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';

这个策略意味着：

  • 所有资源默认只能从同源加载。
  • 脚本只能从同源和 https://cdn.example.com 加载。
  • 完全禁止 <object> 等插件。
  • 禁止 <base> 标签，防止相对路径劫持。

配置CSP是一个渐进的过程，可以从 Content-Security-Policy-Report-Only 开始，根据控制台报告逐步收紧策略，直到没有违规，再切换到强制执行模式。

安全防护从来不是一劳永逸的事情，XSS攻击的手法也在不断演化。作为开发者，我们需要建立起持续关注安全动态的习惯，将安全编码意识变成肌肉记忆。每次写下一行处理用户数据的代码时，都多问一句：“这里，安全吗？” 这套从意识到实践，从后端到前端，从编码到运维的立体防御体系，才是应对XSS这类“经典”漏洞最有效的方法。

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

更多推荐

AI 学习路径：从入门到实战的全景路线图（2026 版）

关于当前最新最热的AI人工智能学习路径分享

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

WPF基础到企业应用系列7——深入剖析依赖属性（WPF/Silverlight核

首先圣殿骑士很高兴这个系列能得到大家的关注和支持，这个系列从七月份开始到现在才第七篇，上一篇发布是在8月2日，掐指一算有二十多天没有继续更新了，最主要原因一来是想把它写好，二来是因为最近几个月在筹备“云计算之旅”系列，所以一再推迟了发布进度。

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

解密 AI Agent 的安全带与催化剂：一文读懂 Harness Engineering 的崛起与落地实践

解密 AI Agent 的"安全带"与"催化剂"：一文读懂 Harness Engineering 的崛起与落地实践 在过去的一两年里，大语言模型（LLM）的火爆催生了 **AI Agent（人工智能智能体）** 的井喷。我们看着 Agent 从最初只能做简单对话的 Bot，演变成如今能够自主规划、调用工具、甚至代替人类编写代码和处理复杂业务流的数字员工。 然而，随着 Agent...

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