csp 是缓解 xss 后果的纵深防御手段，而非根治方案；其核心在于禁用不安全执行方式（如 unsafe-inline、unsafe-eval）并收紧脚本来源，且必须配合安全编码实践。
HTML CSP 和 XSS 防御不是同一类东西
CSP（Content-Security-Policy）是浏览器执行的一套策略机制，XSS（跨站脚本攻击）是一种攻击类型。CSP 不是“XSS 防御方案”，而是**缓解 XSS 后果的纵深防御手段**——它无法阻止所有 XSS 漏洞产生，但能显著降低恶意脚本执行成功的概率。
常见误解是：加了 script-src 'self' 就等于防住了 XSS。实际中，如果页面存在 innerHTML = user_input 或 eval() 类型漏洞，攻击者仍可能绕过 CSP（比如通过 javascript:... 伪协议、内联事件、或利用白名单中的第三方库漏洞）。
哪些 CSP 配置对 XSS 最关键
真正起效的 CSP 规则必须同时满足「禁止不安全执行方式」+「收紧脚本来源」：
-
script-src 'self' https://cdn.example.com：禁止内联脚本（<script>...</script>）、eval()及其变体（setTimeout(string),setInterval(string),Function(string)） -
default-src 'none'：显式关闭所有资源默认加载行为，避免遗漏导致宽松回退 -
unsafe-inline和unsafe-eval必须彻底移除——哪怕只加一个单引号，就等于关掉了 CSP 的核心防护能力 -
style-src 'self'要同步设置，否则攻击者可通过<div style="background:url(javascript:...)"> 绕过 <h3>为什么本地开发时 CSP 常常“不生效”</h3> <p>原因往往不是规则写错，而是策略未被浏览器正确接收：</p> <ul> <li>HTTP 响应头优先级高于 <code><meta http-equiv="Content-Security-Policy">，但<meta>不支持report-uri/report-to，也不支持某些指令（如frame-ancestors） - 使用
<meta>时，必须放在最前面，且不能有前置字符（包括空格、BOM、注释） - 本地
file://协议下，大多数浏览器完全忽略 CSP（Chrome/Firefox 均如此），必须走 HTTP(S) 服务才能测试真实效果 - 开发服务器（如 Vite、Webpack Dev Server）默认不注入 CSP 响应头，需手动配置中间件或插件（例如 Express 中用
helmet.contentSecurityPolicy()）
CSP 报告收集和误报调试很关键
上线后第一周，务必开启报告机制，否则你根本不知道规则是否误杀合法功能：
- 用
report-to+Reporting-Endpoints（现代推荐）或report-uri（已废弃但兼容性好）接收违规日志 - 常见误报场景：
webpack热更新依赖eval()，React DevTools注入内联脚本，Vue模板编译器动态生成函数——这些在生产环境通常可关闭 - 不要一上来就设
Content-Security-Policy: default-src 'none'上线，先用Content-Security-Policy-Report-Only头观察至少 48 小时 - 报告里看到大量
blocked-uri: "data"，说明页面用了 base64 内联资源（如img src="data:image/png,..."），需在img-src中显式加data:
最常被忽略的是：CSP 的有效性高度依赖前端运行时行为。哪怕响应头完美无缺，只要代码里还有 element.innerHTML = '<script>...</script>' 这种写法，XSS 依然成立——策略管不住代码本身。
