content-security-policy 是一个 http 响应头，用于声明浏览器允许加载的资源来源；它不是防火墙或自动修复 xss 的银弹，而是需精确配置的声明式防线，漏配指令或写错规则将导致功能阻断或失效。
Content-Security-Policy 是什么，不是什么
Content-Security-Policy 是一个 HTTP 响应头，用来告诉浏览器“只允许从哪些来源加载脚本、样式、图片、iframe 等资源”。它不是防火墙，也不是能自动修复 XSS 的银弹；它是一道声明式防线——你写错一条规则，就可能直接阻断正常功能，或者形同虚设。
- 它不阻止服务端漏洞，只约束浏览器行为
- 它对内联脚本（比如
<script>alert(1)</script>）和eval()默认拦截，但得靠你自己关掉'unsafe-inline'或'unsafe-eval'才生效 - 它的指令（如
script-src、style-src）彼此独立，漏配一个，对应资源就可能被恶意注入利用
怎么加才不会让页面白屏或报错
加错 Content-Security-Policy 最常见的结果是：JS 不执行、CSS 不加载、字体炸开、第三方统计失效。核心矛盾在于「开发时宽松」和「上线时严格」之间没过渡。
- 用
Content-Security-Policy-Report-Only头先试跑，配合report-uri或report-to收集违规日志，别一上来就block -
script-src至少得包含你实际用到的所有来源：比如用了 CDN 的 Vue，就得写script-src 'self' <a href="https://www.php.cn/link/e5204077564bd260afdcd598f8048f45">https://www.php.cn/link/e5204077564bd260afdcd598f8048f45</a>；用了内联初始化代码，就得加'unsafe-inline'（不推荐）或改用nonce -
font-src容易被忽略，Google Fonts、iconfont 都要显式放行，否则图标全变方块 - 开发环境建议用 Meta 标签临时测试：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">，但注意 Meta 不支持report-uri
nonce 和 hash 怎么选，为什么不能混用
nonce 和 hash 都是用来绕过 'unsafe-inline' 的合法方式，但机制完全不同，混用反而增加维护成本。
-
nonce是每次响应动态生成的随机 Base64 字符串，比如nonce="EaWvVzB8ZQ=="，必须和服务端渲染同步；Node.js 用 Express 可以在模板里插值，PHP 要确保每次请求都重生成 -
hash是对内联脚本内容做 SHA256 后 base64，比如sha256-BqUu...=，适合固定不变的初始化代码；但只要 JS 内容变一点，hash 就失效，CI/CD 里得自动算 - 别在一个策略里同时写
script-src 'nonce-xxx' 'sha256-yyy'：浏览器会按顺序匹配，一旦 nonce 匹配成功，后面 hash 就不看了；更糟的是，如果 nonce 生成失败，整个 script-src 就退化成空——脚本全挂 - 实际项目中，优先用
nonce+ 外部 JS，把内联逻辑尽量抽离；真要保留少量内联，再补 hash
常见报错和调试技巧
浏览器控制台里看到 Refused to load the script because it violates the following Content Security Policy directive 这类提示，说明策略已生效，但配置有偏差。
- 查看 Network → Response Headers，确认
Content-Security-Policy是否真的下发，有些 Nginx 或 CDN 会覆盖后端设置 - 在 DevTools → Application → Frames → Content Security Policy 查看当前生效的完整策略，比 console 日志更全
- 报错信息末尾常带
source: inline或source: <a href="https://www.php.cn/link/26c667e4a9ee309462b2c43d90482bed">https://www.php.cn/link/26c667e4a9ee309462b2c43d90482bed</a>，直接对应到具体哪条指令该调整 - 如果用了 Webpack/Vite，注意它们生成的 runtime 脚本可能是内联的，得配
__webpack_nonce__或启用trustedTypes插件
CSP 的复杂性不在语法，而在它强制你理清整个前端资源链路——谁加载了什么、从哪来、有没有中间代理改写、是否依赖用户输入拼接 URL。漏掉任意一环，策略就变成半吊子防御。
