CSP 内容安全策略实战：从报告模式到拦截模式

在 Web 安全领域，XSS（跨站脚本攻击）长期占据 OWASP Top 10 的显著位置。尽管开发者通过输入过滤、输出编码等手段不断加固应用，但面对日益复杂的攻击向量，单一防御层往往力不从心。CSP（Content Security Policy，内容安全策略）作为一种纵深防御机制，能够从浏览器层面限制资源加载与脚本执行，成为对抗 XSS 和点击劫持等攻击的利器。然而，直接启用严格的 CSP 策略可能导致页面功能大面积失效。本文将带你从报告模式起步，逐步过渡到拦截模式，实现平滑、可观测的安全加固。

一、为什么需要 CSP？

传统的 XSS 防御依赖服务端对用户输入的净化，但一旦遗漏某个参数或编码上下文出错，攻击者便能注入恶意脚本。CSP 通过白名单机制告诉浏览器：只允许加载指定来源的脚本、样式、图片等资源。即使攻击者成功注入了 <script> 标签，浏览器也会因为来源不在白名单而拒绝执行。

CSP 还能有效缓解以下威胁：

• XSS：阻止内联脚本和未授权外部脚本执行。
• 点击劫持：通过 frame-ancestors 指令控制页面能否被嵌入 iframe。
• 数据泄露：限制 connect-src 防止敏感数据外传。
• 混合内容：强制 HTTPS 加载资源。

与 SQL 注入、CSRF 等攻击不同，XSS 直接作用于用户浏览器，CSP 恰好在这一层构建了最后一道防线。CSRF 通常需要配合 token 防御，而 CSP 能间接增加攻击者利用 XSS 发起 CSRF 的难度。

二、CSP 的两种工作模式

CSP 通过 HTTP 响应头 Content-Security-Policy 或 <meta> 标签下发。其核心指令包括 default-src、script-src、style-src、img-src、connect-src 等。

1. 报告模式（Report-Only）

使用 Content-Security-Policy-Report-Only 头，浏览器会检查违规行为，但不会阻止任何资源加载或脚本执行。违规报告会发送到你指定的 report-uri 或 report-to 端点。

适用场景：策略上线前的测试阶段。你可以在不影响线上用户的前提下，收集所有潜在的违规事件，了解现有页面依赖了哪些外部资源、是否存在内联脚本等。

2. 拦截模式（Enforce）

使用 Content-Security-Policy 头，浏览器会强制执行策略。任何违反规则的资源都会被阻止，同时发送违规报告（如果配置了报告端点）。

适用场景：经过报告模式验证、策略调整完毕后的正式上线阶段。

三、实战步骤：从报告到拦截

步骤 1：梳理资源清单

在制定策略前，先盘点页面加载的所有资源类型及来源：

• 内部脚本：self
• CDN 脚本：如 https://cdn.example.com
• 内联脚本：<script>...</script> 或事件处理器 onclick
• 内联样式：style 属性或 <style> 块
• 图片、字体、AJAX 请求等

步骤 2：部署报告模式

假设你希望最终策略为：

default-src 'self';
script-src 'self' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://images.example.com;
connect-src 'self' https://api.example.com;
report-uri /csp-report;

先以报告模式下发：

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; connect-src 'self' https://api.example.com; report-uri /csp-report;

同时，在服务端实现 /csp-report 端点，接收并记录浏览器发送的 JSON 格式违规报告。报告内容包含 blocked-uri、violated-directive、document-uri 等关键字段。

步骤 3：分析报告并调整策略

运行报告模式一到两周，收集足够数据。常见问题及处理方式：

• 大量内联脚本违规：考虑将内联脚本外移，或使用 nonce 或 hash 白名单。例如，为每个响应生成随机 nonce：script-src 'nonce-abc123'，并在 <script nonce="abc123"> 中引用。
• 第三方库加载失败：将对应域名加入 script-src 或 style-src。
• eval 相关违规：若必须使用 eval，可添加 'unsafe-eval'，但应优先重构代码避免使用。
• 数据 URI 图片：在 img-src 中添加 data:。

注意：'unsafe-inline' 会削弱 CSP 对 XSS 的防护能力，应尽量避免。如果必须使用内联样式，可仅对 style-src 开启。

步骤 4：切换到拦截模式

当报告数量降至可接受范围（理想为零），将响应头从 Content-Security-Policy-Report-Only 改为 Content-Security-Policy。建议采用渐进式切换：

• 先对部分低风险页面启用拦截模式。
• 观察错误日志和用户反馈。
• 逐步扩大范围，直至全站生效。

步骤 5：持续监控与迭代

CSP 不是一次性配置。随着业务迭代，新引入的第三方服务可能违反策略。保留 report-uri 并设置告警，定期审查报告。同时，关注 CSP Level 3 的新特性，如 strict-dynamic，它允许通过 nonce 信任的脚本动态加载其他脚本，简化白名单管理。

四、CSP 与其他安全措施的协同

CSP 不能替代输入验证和输出编码，而是与之形成互补。对于 SQL 注入，仍需参数化查询；对于 CSRF，需使用 SameSite Cookie 和 Anti-CSRF Token。CSP 的价值在于：即使 XSS 防御被突破，攻击者也无法轻易执行恶意脚本或窃取数据。

此外，结合 X-Content-Type-Options: nosniff、X-Frame-Options 或 CSP 的 frame-ancestors，可以构建更完整的浏览器安全加固体系。

五、常见陷阱与建议

• 不要直接复制网上的策略：每个应用的资源来源不同，必须量身定制。
• 慎用 'unsafe-inline' 和 'unsafe-eval'：它们会大幅降低 CSP 的防护效果。
• 报告端点需做限流：避免被大量报告打垮。
• 测试覆盖要全面：包括登录、支付、富文本编辑等关键路径。
• 使用工具辅助：如 Google 的 CSP Evaluator、Report URI 服务等。

结语

从报告模式到拦截模式，CSP 的落地是一个观察、调整、验证的循环过程。它需要开发、运维和安全团队的协作，但回报是显著的：一道抵御 XSS 和点击劫持的坚固屏障。在 Web 安全威胁日益复杂的今天，CSP 不应是可选加分项，而应成为安全加固的标准配置。现在，就从报告模式开始，迈出第一步吧。

未经允许不得转载：任鹏个人博客 » CSP 内容安全策略实战：从报告模式到拦截模式