通过 Report-Only、资源清单和关键页面回归逐步部署 CSP，避免上线即大面积破坏页面功能。
内容安全策略可以约束页面资源与脚本执行，但把一条严格策略直接复制到所有页面，可能破坏登录、支付跳转或富文本功能。成功部署的关键是先理解页面实际依赖，再把预期行为写进策略。
先整理脚本和资源清单
按页面模板列出自有脚本、第三方脚本、内联代码、样式、字体、图片和连接目标。给每个第三方依赖标注用途与负责人；无人能解释用途的依赖应先调查，而不是因为浏览器报错就加入允许清单。
MDN 说明 Content-Security-Policy-Report-Only 只产生违规报告，不执行该策略的拦截；正式 CSP 与报告模式可以同时存在。报告模式必须通过 HTTP 响应头部署，不能用 meta 元素替代。
把报告转成可行动的问题
- 在测试或受控灰度页面部署候选策略，并配置能接收报告的端点。
- 按页面、指令和资源来源聚合报告，剔除浏览器扩展等噪声，避免逐条人工追踪所有事件。
- 对自有代码评估 nonce 或 hash 等适用方案，修正不必要的动态执行，而不是持续扩大通配范围。
- 通过关键业务回归后，分模板切换到执行模式，保留上一版策略和回滚路径。
上线验收看哪些结果
覆盖登录、搜索、表单提交、附件预览和必要的外部组件。允许的资源应正常工作，测试中未授权的资源应按策略被阻止。报告接收端还应限制请求体与频率，并对可能包含 URL 参数的数据脱敏。
CSP 是纵深防御的一层，不能代替正确的输出编码、输入处理和依赖维护。验收报告应明确哪些页面已经执行策略、哪些仍处于观察阶段，避免把“有响应头”误写成全站已经受到同等保护。
参考：MDN：Content Security Policy。核对日期：2026年10月4日。
