nonce必须动态生成且与script-src响应头严格匹配，否则失效；常见错误包括响应头缺失、值不一致、静态写死、未叠加'self'等合法源，且仅http响应头有效，meta标签和file://协议下无效。
nonce 不是“加个属性就防 XSS”，它必须和 HTTP 响应头中的 script-src 指令严格配对，且每次请求的值必须唯一、不可预测、不复用——否则攻击者可提前猜出或窃取 nonce 值，直接绕过整个策略。
为什么 inline script 加了 nonce 还被浏览器拦截
常见错误是服务端没在 Content-Security-Policy 响应头里写 script-src 'nonce-xxx'，或者写了但 xxx 和 HTML 中 <script nonce="xxx"></script> 的值不一致（比如大小写、空格、Base64 编码错误）。更隐蔽的是：Nginx/Apache 配置中用了变量插值但未正确转义，导致实际响应头里出现 nonce- 后面跟空值或乱码。
验证方式很简单：curl -I https://yoursite.com 查看响应头是否含完整 script-src 'nonce-...；再打开 DevTools → Elements，确认 <script></script> 标签的 nonce 属性值与响应头中完全一致（逐字符比对，包括等号前后）。
nonce 必须随每次 HTTP 请求动态生成
静态写死的 nonce（如硬编码为 "abc123"）等于没设。攻击者只要一次拿到该值，就能在后续任意页面注入带相同 nonce 的恶意脚本。
- Node.js（Express）示例：用
crypto.randomBytes(16).toString('base64')生成，注入模板时传入上下文，确保每个响应独立 - PHP 示例：用
bin2hex(random_bytes(16))，避免md5(time())这类可预测方式 - Nginx 不支持真随机，若必须用变量（如
$request_id），需确认该变量由 upstream 动态生成且不可被客户端控制
script-src 指令里不能漏掉其他合法入口
只配 script-src 'nonce-xxx' 是危险的——它会直接阻断所有非内联脚本，包括 <script src="/app.js"></script>、import()、甚至现代框架的 runtime chunk 加载。必须显式叠加允许来源：
正确写法示例：script-src 'self' 'nonce-xxx' https://cdn.example.com;
注意三点：
-
'self'和'nonce-xxx'是并列关系，不是替代关系；缺一不可 - 第三方 CDN 必须显式列出，不能靠
*:或https:这种宽泛写法（CSP v3 已弃用） - 如果用了
strict-dynamic，则'nonce-xxx'仅用于初始脚本，后续动态创建的<script></script>依赖其父脚本签名，此时不能再混用'self'，否则策略冲突静默失败
浏览器兼容性与开发调试陷阱
Safari 16.4 之前版本完全忽略含 nonce- 的 script-src 指令；Chrome 124+ 开始拒绝解析 <meta http-equiv="Content-Security-Policy"> 中的 nonce —— 所以开发阶段用 meta 标签测试 nonce 是无效的，必须走响应头。
另一个易踩坑点：file:// 协议下所有 CSP 全面失效，本地双击 HTML 文件永远测不出效果。必须通过 localhost 或真实域名访问。
真正难的不是生成 nonce，而是确保它从服务端生成、透传到模板、拼接到响应头、且全程不被中间件截断或缓存复用——任何一个环节出错，都会让策略变成“形同虚设”的假防护。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
