csp必须通过http响应头配置才真正有效，在生产环境基本无效，因其被响应头优先忽略、不支持report-to/frame-ancestors等关键指令、无法动态生成nonce，且chrome 124+已限制script-src等核心功能。
为什么直接写 http-equiv="content-security-policy" 通常无效
浏览器根本不会把 http-equiv 当作真正的 CSP 响应头处理——它只模拟部分 HTTP 头（比如 refresh 或 content-type），而 Content-Security-Policy 不在支持列表里。Chrome、Firefox、Safari 都明确忽略这种写法，控制台也不会报错，但策略完全不生效。
常见错误现象：script 标签内执行 alert(1) 仍能弹窗；内联事件如 onclick="alert(1)" 未被拦截；通过 eval() 或 innerHTML 注入的脚本照常运行。
- 必须通过 HTTP 响应头（
Content-Security-Policy）或<meta>的http-equiv**等效替代机制**（仅限部分旧场景）才能启用 CSP -
<meta http-equiv="content-security-policy" content="...">仅在 HTML 文档顶层（非 iframe）且无服务端响应头时，被部分浏览器“降级支持”，但行为不一致、不可靠 - 现代部署必须优先走服务端头：Nginx、Apache、Express、Django 等都支持直接设置响应头
Content-Security-Policy 响应头中必须禁用的危险指令
CSP 的防御效果高度依赖指令组合，几个看似方便的值实际等于开后门：
-
unsafe-inline：允许所有内联<script></script>、<style></style>和内联事件（onclick等），XSS 几乎无法缓解 -
unsafe-eval：放行eval()、setTimeout(string)、Function(string)等动态代码执行，攻击者极易绕过 - 空
default-src或仅设为'self'：若未显式覆盖script-src，则继承default-src 'self'，但很多框架（如 Vue、React）依赖内联nonce或hash，需单独配置 - 使用
*通配符（如script-src *）：等同于开放所有域，失去域名白名单意义
正确做法是：显式声明 script-src，优先用 nonce 或 sha256-... 哈希值约束内联脚本，外部资源限定具体域名（如 https://cdn.example.com）。
如何让 <meta> 写法在开发阶段勉强可用（仅限测试）
如果实在无法改服务端（比如静态托管平台限制头设置），可尝试用 <meta>，但必须满足三个硬条件：
- 标签必须放在
最前面，且在任何<script></script>或<link>之前 - 文档不能有服务端返回的
Content-Security-Policy响应头（否则会被忽略） - 只对顶层页面生效，iframe 内嵌页完全不继承，也不触发 report-only 模式
示例（仅用于本地验证逻辑）：
<meta http-equiv="content-security-policy" content="default-src 'none'; script-src 'self' 'nonce-abc123'; style-src 'self'; img-src 'self' data:;">
注意：nonce 值必须每次响应动态生成并同步到对应 <script nonce="abc123"></script>，静态写死会失效；data: 允许 base64 图片，但若不需要，应移除以防被滥用。
report-uri 和 report-to 在 CSP 中的实际作用差异
两者都用于收集违规报告，但机制完全不同：
-
report-uri是旧标准（已废弃），直接向指定 URL 发送 POST 请求，JSON 格式，服务端需自行解析 -
report-to是新标准，需先通过独立的Report-To响应头声明端点组名（如{"group":"csp-reports","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}），再在 CSP 中引用该组名：report-to csp-reports - 现代浏览器（Chrome 93+、Edge 93+）优先支持
report-to；Firefox 已弃用report-uri；Safari 尚未实现report-to - 无论用哪个，报告本身不阻断脚本执行，仅用于审计——别误以为加了就等于防御增强
真正关键的是：报告内容包含攻击载荷片段（如被拦截的内联脚本内容），务必检查日志是否暴露敏感字段，避免二次泄露。
