nonce属性必须写在<script>或<style>标签上，不能写在<meta>中；浏览器只认HTTP响应头Content-Security-Policy与对应标签nonce属性严格配对生效，<meta http-equiv="Content-Security-Policy">完全不支持nonce。
nonce属性必须写在<script>或<style>标签上，不能写在<meta>里</script>
浏览器只认 HTTP 响应头里的 Content-Security-Policy 和对应标签的 nonce 属性配对生效。<meta http-equiv="Content-Security-Policy"> 完全不支持 nonce，哪怕你写了 script-src 'nonce-abc' 也无效——这是最常被忽略的硬性限制。
正确做法只有两种：
- 服务端通过
res.setHeader('Content-Security-Policy', ...)设置响应头（Node.js）、response.headers['Content-Security-Policy'] = ...（Python/Django）或 Nginx 的add_header -
<script nonce="xxx">或<style nonce="xxx">必须显式出现在 HTML 源码中，且值与响应头里'nonce-xxx'完全一致
nonce值生成和注入必须同步，且每次请求都要新生成
常见错误是模板渲染早于响应头设置，或者把 nonce 硬编码进构建产物（如 Vite 的 html.cspNonce 配成固定字符串）。一旦复用、缓存或前端拼接，机制立刻失效。
安全做法：
立即学习“前端免费学习笔记（深入）”；
- 用服务端加密安全随机函数：Node.js 中
crypto.randomBytes(16).toString('base64').replace(/[+/=]/g, '')；PHP 中bin2hex(random_bytes(16))；Django 中get_random_string(32) - 确保 nonce 在模板渲染前已生成，并作为变量传入（如 EJS 的
、Jinja2 的{{ nonce }}） - 避免模板引擎自动转义破坏 nonce 值：比如 Jinja2 中必须用
{{ nonce|safe }}，EJS 中用而非
多个<script>标签共用同一个 nonce 值，但不能跨请求复用</script>
一个页面内所有需放行的内联脚本（包括框架注入的初始化脚本，如 window.__INITIAL_STATE__）都必须使用**同一** nonce 值。但这个值绝不能在下次 HTTP 请求中再次使用——CDN 缓存、反向代理缓存或 SSR 模板静态化都会导致 nonce 失效。
典型陷阱：
- Vite 构建时设了
html.cspNonce: 'abc'→ 所有用户加载同一 nonce，形同虚设 - Express 中间件没加
res.locals.nonce，而是全局变量缓存了 nonce → 多个请求共享 - Goober 或 emotion 等 CSS-in-JS 库依赖
window.__nonce__，但你忘了在<script>标签里先赋值 → style 标签没带 nonce，被style-src拦截
strict-dynamic 和 nonce 必须同时启用，且首个执行脚本必须带 nonce
只写 script-src 'nonce-xxx' 不够——它只放行那个带 nonce 的内联脚本，后续通过 eval()、innerHTML 或动态 document.createElement('script') 创建的脚本仍会被拦。要让它们合法执行，必须加 'strict-dynamic'。
但注意顺序和前提：
- 响应头必须是
script-src 'nonce-xxx' 'strict-dynamic'，不能写成script-src 'self' 'strict-dynamic'（'self'会覆盖'strict-dynamic'） - 首个执行的脚本（通常是首屏 JS 初始化逻辑）**必须**带该 nonce，否则
'strict-dynamic'不触发 -
onclick、onload这类内联事件处理器不受 nonce 影响，必须改用addEventListener，否则照样报错
真正难的不是写对一行 nonce="xxx"，而是确保服务端每次响应都生成新值、同步塞进响应头和所有目标标签、且不被任何中间层（缓存、CDN、构建工具）偷偷固化。漏掉任意一环，CSP 就退回到靠 'unsafe-inline' 维持功能的状态。
