CSP 有效性怎么看
「有 CSP 头」和「CSP 能防住跨站脚本」是两回事。判断有效性要看策略的关键指令：script-src 是否含 unsafe-inline 或 unsafe-eval、是否使用宽泛通配源、object-src 与 base-uri 是否受限。落地方式同样重要：直接上强制策略容易打断业务，稳妥做法是先以仅上报模式收集违规，再逐步收紧到强制，并覆盖全部关键页面。
基本信息
| 关键指令 | script-src 强度、通配源、object-src、base-uri、frame-ancestors |
|---|---|
| 加固手段 | nonce 或 hash 替代 unsafe-inline；严格来源清单 |
| 上线流程 | 仅上报模式收集违规 → 修正 → 切换强制 |
| 违规收集 | 配置上报端点并接入日志 |
| 覆盖范围 | 全部关键页面，含登录、支付与后台 |
典型使用场景
- 安全基线核查中判断 CSP 是否具备实际防护能力
- 为跨站脚本问题提供纵深防御建议
- 评估策略上线的推进方式：是否已有仅上报模式的过渡
- 排查「上了 CSP 但脚本仍能执行」的原因
- 修复验证：确认 unsafe 指令已去除且关键页面全覆盖
检查要点
检查要点
# 1. 抓取关键页面的 CSP 头并逐项解读
curl -sI https://example.com/ | grep -i 'content-security-policy'
# 2. 标出弱指令：unsafe-inline、unsafe-eval、宽泛通配源
# 3. 核对 script-src 是否覆盖全部脚本入口（含第三方统计与广告脚本）
# 4. 检查是否配置了违规上报端点（仅上报模式的报告地址）
# 5. 建议路径：nonce 或 hash + 仅上报模式过渡，再切换到强制策略现状与判断
| 现状 | 有效性 | 处置 |
|---|---|---|
| script-src 含 unsafe-inline | 对跨站脚本缓解有限 | 建议改用 nonce 或 hash |
| 使用宽泛通配源 | 外部脚本可被任意引入 | 收敛到具体域名 |
| object-src 与 base-uri 未限制 | 可被跳转劫持与插件加载 | 补充限制 |
| 关键页面未覆盖策略 | 缺口明显 | 统一在网关或框架层注入 |
存在 CSP 不等于有防护：含 unsafe-inline 的宽松策略对跨站脚本的缓解作用非常有限，判断要看指令内容而不是头部是否存在。
直接强制新策略可能导致业务中断：缺少仅上报模式的过渡，页面脚本被拦截会造成大面积功能不可用。