内容安全策略 (CSP).

内容安全策略通过 Content-Security-Policy 响应头(或 meta 元素)下发,针对每种资源类型施加细粒度的白名单:script-src、style-src、img-src、connect-src、frame-ancestors 等。它由 W3C 标准化,而 CSP Level 3 引入了使严格策略切实可行的各项原语。作为一项纵深防御措施,它能显著降低 XSS、点击劫持(通过 frame-ancestors)以及混合内容带来的影响,但并不能取代输入校验与输出编码。

基于主机的白名单是经典误区。 Google 的研究(论文 CSP Is Dead, Long Live CSP!,分析了约十亿个页面)发现,绝大多数基于主机的策略都可被轻易绕过——通常是因为白名单中的某个 CDN 同时提供了 JSONP 端点,或托管了可被当作 gadget 利用的过时 Angular/AngularJS 构建版本。现代的答案是基于 nonce 的严格 CSP:每个响应都生成一个全新的随机 nonce(script-src 'nonce-r4nd0m'),内联脚本携带该 nonce,而注入的、不带 nonce 的 <script> 根本不会执行。将 nonce 与 'strict-dynamic' 搭配使用,可让受信任的脚本加载自身依赖,同时完全忽略主机白名单,从而使策略简短且与 CDN 无关。请始终加上 object-src 'none' 和 base-uri 'none',以封堵通过 <object> 与 <base> 标签实现的绕过。

使用 Content-Security-Policy-Report-Only 可安全地进行灰度上线:它不强制执行任何限制,但会通过 report-to/report-uri 发送 JSON 格式的违规报告,让你能够针对真实流量调优策略,再切换到强制执行模式。GitHub、Google 和 Dropbox 都在生产环境中运行着基于 nonce 的严格 CSP。请记住,该响应头由浏览器在客户端执行,因此它只能缓解而非阻止服务端注入。

flowchart TD
  A[服务器生成响应] --> B[每个请求生成全新随机 nonce]
  B --> C["Header: script-src 'nonce-abc123' 'strict-dynamic'; object-src 'none'; base-uri 'none'"]
  C --> D[浏览器解析页面]
  D --> E{脚本是否携带匹配的 nonce?}
  E -->|是:合法的内联脚本| F[执行 + strict-dynamic 加载其依赖]
  E -->|否:XSS 注入的脚本标签| G[被阻止]
  G --> H[向 report-to 端点发送违规报告]
  style F fill:#27ae60,color:#fff
  style G fill:#c0392b,color:#fff