strict-dynamic 加上后第三方脚本还是被拦截，怎么回事？
我给页面加了 CSP 的 strict-dynamic 策略，本意是让通过可信脚本动态加载的资源能正常执行，但像 Google Tag Manager 这类第三方脚本还是被浏览器拦了，控制台报“blocked by Content Security Policy”。是我理解错了 strict-dynamic 的用法吗？
当前 CSP 头是这样设置的：
<meta http-equiv="Content-Security-Policy"
content="script-src 'self' 'unsafe-inline' 'strict-dynamic';">按理说加上 ‘strict-dynamic’ 后应该忽略 ‘self’ 和 ‘unsafe-inline’，只信任由已授权脚本加载的内容，但实际效果好像不是这样……
strict-dynamic是干什么的吧。它的主要作用是在script-src中启用一个动态机制，允许由那些已经被明确信任的脚本所动态生成或加载的其他脚本执行。简单来说，就是说你有一个可信的脚本A，这个脚本A可以动态加载其他脚本B，那么B也能被执行。但是，这里需要注意的是，
strict-dynamic并不会完全忽略script-src中的其他指令，比如'self'和'unsafe-inline'。这些指令仍然有效，并且在某些情况下会被优先考虑。你提到的
Google Tag Manager这样的第三方脚本，通常需要明确声明它们的来源。光靠strict-dynamic是不够的。你需要指定这些脚本的具体来源，这样才能确保浏览器知道哪些外部资源是可以被加载和执行的。解决这个问题，你可以按照下面的步骤来调整你的 CSP 设置：
1. 确定第三方脚本的来源：首先，你需要知道你要加载的第三方脚本（比如 Google Tag Manager）的具体域名或路径。对于 Google Tag Manager，通常是
https://www.googletagmanager.com。2. 更新 CSP 头：在你的
script-src中，除了保留strict-dynamic之外，还需要添加这些第三方脚本的具体来源。这样浏览器就知道哪些外部脚本是允许的。下面是更新后的 CSP 头的一个例子：
在这个例子中，我们不仅保留了
strict-dynamic，还添加了https://www.googletagmanager.com作为允许的脚本来源。这样，Google Tag Manager 加载的脚本就能顺利执行了。记得，如果你有其他的第三方服务，也需要相应地把它们的域名添加到
script-src中。最后，别忘了在修改 CSP 设置后，要刷新你的页面或者清除浏览器缓存，以确保新的 CSP 头生效。希望这能帮到你，如果有其他问题也可以继续聊。有时候 CSP 的配置确实有点绕，不过多试几次就会慢慢熟悉了。
核心问题在于： strict-dynamic 需要配合 nonce 或 hash 一起使用才有意义。你光写个
'strict-dynamic'上去，浏览器不知道该信任哪些脚本。strict-dynamic 的设计意图是这样的：假设你用