nonce属性是CSP中用于精准放行可信内联脚本的一次性Base64编码值，服务端必须每次响应动态生成并同步注入HTML标签和Content-Security-Policy响应头，二者严格匹配才生效；若硬编码、复用、未同步或含非法字符，nonce即失效。
什么是 nonce 属性，它为什么能阻止内联脚本被 CSP 拦截
nonce 不是随机字符串，而是由服务端在每次响应时生成的一次性 Base64 编码值，必须与 HTTP 响应头 Content-Security-Policy 中的 script-src 'nonce-<em>xxx</em>' 完全匹配，浏览器才允许执行对应 <script nonce="xxx"> 的内联脚本。关键点在于：nonce 值不能硬编码、不能复用、不能从客户端生成——否则攻击者可预猜或重放。
如何在服务端动态注入 nonce 值到 HTML 和 CSP 头
常见错误是只往 HTML 里塞了 nonce 属性，却忘了同步设置响应头，或者两个值不一致。正确做法是：在渲染 HTML 前生成一次 nonce（如 Node.js 中用 crypto.randomBytes(16).toString('base64')），然后同时做两件事：
- 把该值插入 HTML 中所有需放行的内联
<script>标签：<scriptnonce="EaBcDfGhIjKlMnOpQrStUvWxYz">…</script> - 在响应头中写入：
Content-Security-Policy: script-src 'self' 'nonce-EaBcDfGhIjKlMnOpQrStUvWxYz' - 注意：如果用了多个
<script>，全部都要加相同 nonce；但若页面有多个请求（如 AJAX 后续加载），每个响应必须用新 nonce
哪些场景下 nonce 会失效或被绕过
nonce 看似简单，但几个典型坑会导致策略形同虚设：
- 使用了
unsafe-inline或unsafe-eval—— 这会让整个 nonce 机制退化，直接无视 nonce 校验 - 服务端模板中拼接了用户输入到
<script>内（比如<script nonce="...">var name = "${userInput}";</script>），可能引入 XSS，此时 nonce 反而帮攻击者“合法执行”恶意代码 - CDN 或反向代理缓存了带固定 nonce 的 HTML 响应（比如把
nonce="abc"缓存一天），导致所有用户共享同一 nonce，失去“一次性”意义 - HTTP/2 Server Push 推送的资源若含内联脚本，但未同步推送更新后的 CSP 头，浏览器会因 nonce 不匹配拒绝执行
Vue/React 等框架中怎么安全处理 inline script 的 nonce 注入
框架默认不处理 nonce，需要手动介入渲染流程。以 Express + EJS 为例，你得在 res.render() 前把 nonce 放进 locals；而 Vue SSR（如 Nuxt）需在 entry-server.js 中通过 context.nonce 透出，并在模板中写成 <script :nonce="$ssrContext.nonce">。更关键的是：框架生成的内联初始化脚本（如 window.__INITIAL_STATE__）也必须带上 nonce，否则会被 CSP 拦掉——很多人只记得给业务脚本加，漏了框架自己写的那部分。
立即学习“前端免费学习笔记（深入）”；
复杂点在于，nonce 必须在服务端渲染阶段就确定，不能等到客户端 hydrate 时再算；而且一旦用了 script-src 'strict-dynamic'，nonce 就不再是必需项，但兼容性差（IE 全挂，旧版 Safari 不支持），所以生产环境仍建议保留 nonce 作为 fallback。
