CSP Header 风险分析
解析现有 Content-Security-Policy，检查 Wildcard、Unsafe、HTTP、重复和缺失控制
工具说明
CSP Header 风险分析工具把现有 Content-Security-Policy 或 Report-Only Header 解析成 Directive 与 Source List，再应用聚焦的静态规则集。它会提示重复 Directive、全局 Wildcard、unsafe-eval、unsafe-inline、HTTP Source、data: Script Source、'none' 与其他来源混用、缺少 default-src、object-src 未设 none，以及缺少 base-uri 或 frame-ancestors 的建议。结果按 High、Medium、Low 排序，未知 Directive 仍保留供人工检查拼写和浏览器支持。本工具不是浏览器 CSP Evaluator：Directive 继承、Nonce/Hash 有效性、strict-dynamic、Redirect、Report 投递、应用 Route 和运行时违规仍需在 Report-Only 与真实浏览器中测试。
场景配方
用 Report-Only 证据准备 CSP 收紧变更
目标：把静态 Finding 当评审输入，而不是安全结论
- 分析当前 Enforced Policy，按应用依赖分类每个 High 或 Medium Finding。
- 用 CSP Generator 起草更窄策略，并以 Report-Only 部署到代表性 Route。
- 评审浏览器 Violation Report，修复必需 Source，测试认证和支付流程，再按变更流程 Enforce。
结果：得到同时有静态评审、运行时证据和 Route 测试支持的 CSP 变更。
常见问题
分析器会提示哪些风险？
覆盖常见 Wildcard、Unsafe Keyword、不安全 HTTP、data Script、重复、none 混用和缺失基础项。
它能证明 CSP 安全吗？
不能，静态文本规则无法模拟应用行为、浏览器继承、Endpoint Trust 或运行时违规。
支持 Report-Only Header 吗？
支持该前缀，但不会执行 Report 投递或 Violation Event。
为什么显示未知 Directive？
它可能拼写错误、处于实验、已经废弃或比 Allowlist 更新，需要人工核查浏览器支持。
更严格 CSP 应如何上线？
先使用 Report-Only 收集真实违规，有计划移除依赖，测试关键 Route，再切换 Enforce。
策略会上传吗？
不会，Tokenization、Finding、排序和表格都在本地生成。
继续浏览