XSS攻击的核心在于恶意脚本被注入到网页中并在用户浏览器执行，要彻底堵住这个漏洞，最有效的方法之一就是实施内容安全策略（CSP）。CSP不是某个单一的防护软件，而是一个由服务器通过HTTP头信息（Content-Security-Policy）或<meta>标签发布的、告诉浏览器哪些资源可以被加载和执行的白名单指令集。它直接限制了脚本、样式、图片等资源的来源，即使攻击者成功注入了恶意代码，只要其来源不在白名单内，浏览器就会拒绝执行，从而从根源上遏制了反射型、存储型乃至基于DOM的XSS攻击。

理解CSP的核心：从“允许一切”到“默认拒绝”的范式转变

在没有CSP的传统模式下，浏览器默认信任服务器提供的所有内容，这给了注入的脚本可乘之机。CSP彻底改变了这一安全模型，其哲学是“默认拒绝”。开发者通过定义一系列策略指令（directives），明确告知浏览器哪些资源（如图片、脚本、样式表、字体等）是可信的，可以加载和执行。任何未被明确允许的资源都会被浏览器拦截。例如，一个严格的CSP策略可以完全禁止内联脚本（如<script>alert(‘xss’)</script>）的执行，并只允许从特定可信域名加载外部JavaScript文件，这直接废除了最常见的XSS攻击载体。

CSP指令详解：构建你的安全白名单

CSP策略由多个指令组合而成，每个指令控制一类资源的加载。针对脚本执行防护，以下几个指令最为关键：

script-src： 这是防御XSS最核心的指令。它定义了允许执行JavaScript的合法来源。来源可以是域名（如 https://cdn.trusted.com）、‘self’（指当前网页的源）、‘none’（禁止任何脚本）或‘unsafe-inline’（允许内联脚本，但会削弱安全性）。最佳实践是绝对避免使用‘unsafe-inline’和‘unsafe-eval’（允许eval()等动态代码执行）。

default-src： 这是一个备用指令，为其他未明确指定的指令（如 script-src, img-src）提供默认值。设置一个严格的 default-src ‘self’ 是良好的起点。

object-src 和 base-uri： 这两个指令常被忽视但至关重要。object-src 控制<object>, <embed>, <applet>等插件的加载，应设置为‘none’以防止恶意Flash等对象。base-uri 限制<base>标签的URL，防止攻击者劫改页面内所有相对URL的基准地址。

一个强化脚本安全的基础CSP HTTP头示例如下：

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

这个策略意味着：默认只允许加载同源资源；脚本仅允许来自同源和指定的可信CDN；完全禁止插件对象；限制基准地址为同源。

实施策略：从报告开始，逐步收紧

直接在生产环境部署一个严格的CSP可能会阻断网站正常功能。正确的实施路径是分两步走：

第一步：部署仅报告模式。 使用 Content-Security-Policy-Report-Only 头，而不是强制执行的 Content-Security-Policy 头。浏览器会监测策略违规行为，但不阻止加载，而是将违规报告发送到你通过 report-uri 或 report-to 指令指定的端点。这让你能全面了解现有代码中哪些地方违反了预设策略。

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-violation-report-endpoint;

第二步：分析报告并重构代码。 分析收集到的违规报告。常见问题包括大量内联事件处理器（如onclick）、内联<style>标签或来自第三方分析、广告代码的脚本。解决方案是：移除内联事件处理器，改为使用addEventListener；将内联样式移至外部文件；为必要的第三方脚本在 script-src 中明确添加其安全来源。

第三步：启用强制执行模式。 当报告中的违规降至可接受范围或为零后，将报告头（Content-Security-Policy-Report-Only）替换为强制执行头（Content-Security-Policy）。同时，建议保留报告机制以监控潜在攻击和新引入的违规。

应对挑战：处理第三方代码与现代化开发框架

整合大量第三方小工具、分析或广告代码是实施CSP的主要挑战。盲目添加所有第三方域名会扩大攻击面。解决方案是：

(1) 尽可能使用这些服务商提供的、符合CSP的代码片段（如使用nonce或hash的版本）。

(2) 将必要的第三方域名限制在最小范围，并定期审计其安全性。

对于使用React、Vue、Angular等现代前端框架的单页面应用（SPA），这些框架通常依赖内联事件绑定，看似与禁止‘unsafe-inline’冲突。但实际上，框架在构建时通常能生成唯一的加密随机数（nonce）或计算脚本内容的哈希值（hash）。你可以在CSP策略中使用这些机制来安全地允许特定的内联脚本。

使用Nonce（一次性数字）： 服务器为每个响应生成一个唯一的随机数（nonce），并将其同时插入CSP策略和页面中允许执行的<script>标签中。

// HTTP头
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa';

// 页面中的合法脚本标签

攻击者无法猜测或复现这个随机数，因此其注入的脚本无法执行。

使用Hash（哈希值）： 计算你允许的内联脚本内容的哈希值（如SHA-256），并将其添加到 script-src 指令中。

Content-Security-Policy: script-src 'sha256-abc123...';

只有内容完全匹配该哈希值的脚本块才会被执行。这适用于静态且不变的内联脚本。

CSP的局限与作为纵深防御一环的定位

尽管CSP是防御XSS的利器，但它并非银弹。它无法防范所有类型的攻击，例如服务器端模板注入（SSTI）或纯粹的社会工程学攻击。此外，配置错误（如过于宽松的策略）会使其形同虚设。因此，CSP必须作为纵深防御策略中的关键一层来使用。其他必要的措施包括：对所有用户输入进行严格的输出编码（根据输出上下文选择HTML、JS、CSS编码）；使用HttpOnly和Secure属性的Cookie来保护会话；实施输入验证和过滤；以及定期进行安全审计和渗透测试。

最终，一个精心设计并正确实施的CSP，能将XSS攻击从一种高成功率的严重威胁，转变为一种极难成功、且其攻击尝试能被你监控和记录的“噪音”，从而极大地提升了Web应用的整体安全水位。