如何排查 Content Security Policy script-src 错误

从浏览器违规消息开始

CSP 控制台消息通常会指出被阻止的资源、被违反或实际生效的指令，以及当前策略的一部分。应复制完整消息；截断的截图可能隐藏解释阻止原因的来源表达式或回退关系。

然后在浏览器开发者工具中检查最终文档响应。策略可由 HTTP 响应头传递，也可以在有限条件下由 meta 元素传递。多个策略会同时执行，因此只修改一个策略，未必能解除另一个策略施加的限制。

确认实际生效的脚本指令

script-src 控制 JavaScript 来源；script-src-elem 可对 script 元素覆盖它，script-src-attr 则控制内联事件处理属性。更具体的指令缺失时，浏览器先回退到 script-src；如果 script-src 也不存在，再回退到 default-src。

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

在此策略下，来自其他源的脚本会被阻止，除非另一个适用策略允许该来源。浏览器报告中的 effective-directive 字段可以帮助判断应检查 script-src、更具体的脚本指令，还是 default-src 回退。

使用 CSP 调试器

1. 打开 CSP 调试器。
2. 粘贴当前生效的 Content-Security-Policy 值。
3. 如有条件，粘贴完整的浏览器 CSP 错误。
4. 查看解析后的指令、被阻止资源与实际生效指令。
5. 将建议来源与确实需要信任的资源进行对比。

调试器在浏览器本地分析这些内容。它会解析输入文本并标出可能的修复方向，但不会执行你的应用，也不能替代浏览器测试。

选择范围最小的修复

对于预期的外部脚本，只在适用指令中加入所需的协议和主机。确认是否涉及子域名、端口或重定向。除非安全审查明确接受所有匹配来源，否则应避免 * 或 https: 这类宽泛默认值。

对于预期的内联脚本，优先考虑：

• 在可行时将脚本移动到已允许的外部文件。
• 为每次响应生成密码学随机 nonce，并把相同 nonce 应用于被允许的 script 元素。
• 对固定内联代码块使用稳定 hash，并在内容变化时更新 hash。

不要把 'unsafe-inline' 当作惯性修复。MDN 说明它会允许该指令覆盖的所有内联脚本，并建议使用 nonce 或 hash。

在生产部署前测试

使用 Content-Security-Policy-Report-Only 或预发布环境观察违规，避免意外破坏生产功能。覆盖会动态加载脚本的页面路径和用户操作，并确认 CDN 转换后的最终响应头，而不是只检查源站配置。

确认预期行为后再部署强制策略，并持续监控新的违规。来源列表应保持精确，避免未来第三方被攻破后获得不必要的脚本执行权限。

常见错误

• 实际限制来自 script-src-elem、另一个策略或回退，却只修改 script-src。
• 未检查重定向、准确协议和端口，就直接复制被阻止主机。
• 添加 *、https: 或 'unsafe-inline' 来大范围消除错误。
• 在多个响应中复用静态 nonce。
• 计算 hash 的脚本内容与浏览器收到的内容不同。
• 只测试源站响应头，而 CDN 又添加了其他策略。

局限

Scopeva 只分析你提供的文本，无法看到运行时 DOM 修改、浏览器扩展、框架生成的 nonce、报告端点或未包含在输入中的策略。实际强制行为仍应以浏览器开发者工具和受控预发布测试为准。