strict-dynamic指令允许由可信脚本动态加载的子资源自动获得执行权限，提升现代Web应用安全性。它通过信任传递机制减少对外部源依赖，避免因CDN劫持导致XSS，并兼容SPA框架的动态加载需求。配合nonce或hash使用可建立安全的信任链，防止未授权脚本执行。推荐与传统源列表共存以兼顾兼容性。
Content Security Policy（CSP）的 strict-dynamic 指令是一种用于增强网页脚本加载安全性的机制，它改变了传统基于哈希或内联脚本白名单的策略管理方式，更加适应现代前端应用的动态特性。
什么是 strict-dynamic 指令？
strict-dynamic 是 CSP 3.0 引入的一个关键字，用在 script-src 策略中。它的作用是：只要某个脚本是由已信任的来源（例如通过 nonce 或 hash 显式授权）动态插入的，那么该脚本及其创建的所有子资源（如通过 createElement('script') 加载的脚本）都将被视为可信。
Content-Security-Policy: script-src 'nonce-abc123' 'strict-dynamic';
在这个策略下，带有 nonce="abc123" 的初始脚本被允许执行，而这个脚本后续动态添加的任何脚本也会被自动信任，无需额外配置域名或生成新的 nonce。
如何提升脚本加载的安全性？
传统 CSP 策略常依赖明确列出可执行脚本的源（如 script-src https://trusted.cdn.com），这种方式容易因遗漏或过度放行带来风险。strict-dynamic 通过以下方式改进安全性：
- 减少对外部源的依赖：不再需要将 CDN 域名写入策略，避免因第三方库被劫持而导致 XSS 攻击。
- 信任传递机制：只信任由“可信起点”（带 nonce 的脚本）触发的脚本加载行为，即使这些脚本是运行时动态生成的。
- 兼容现代框架：适用于 React、Vue 等使用动态脚本注入的 SPA 应用，避免因内联事件处理器或动态 import 导致的策略冲突。
- 防止绕过：攻击者即使能注入一个无 nonce 的脚本也无法触发后续脚本加载，因为不满足“信任链”起点条件。
实际使用建议
为最大化安全性和兼容性，推荐结合多种机制：
- 始终为初始内联脚本使用
nonce或hash。 - 在支持 strict-dynamic 的浏览器中，它会覆盖旧的 unsafe 源（如
'unsafe-inline'不再生效）。 - 可与传统源列表共存以兼容老浏览器，例如：
Content-Security-Policy: script-src 'nonce-abc123' 'strict-dynamic' https:;
现代浏览器会优先遵循 strict-dynamic，而旧版浏览器则回退到按域名白名单执行。
基本上就这些。strict-dynamic 的核心价值在于建立“信任链”，让安全策略从静态配置转向动态上下文判断，显著降低误配和被绕过的风险。
