Cloudflare Rocket Loader及服务与strict-dynamic CSP兼容问题求助

以下是几个可行的解决思路，按安全性从高到低排序：

• 使用脚本哈希或Nonce标记Cloudflare的初始注入脚本
  strict-dynamic的核心逻辑是信任已被授权的脚本加载的所有后续资源，所以只要把Cloudflare自动注入的初始脚本（比如Rocket Loader的启动脚本、邮件混淆的注入代码）加入CSP的可信列表，后续它加载的资源就会被自动允许。

  • 获取哈希：打开浏览器控制台，触发CSP报错，错误信息里会直接给出该脚本对应的SHA-256/384/512哈希值，直接复制即可。
  • 配置示例：script-src 'sha256-xxxxxx...' 'strict-dynamic';
  • 如果用Nonce方案，需要在页面每次请求时生成唯一nonce值，同时在CSP头和Cloudflare注入的脚本标签上添加nonce="你的nonce值"。不过部分Cloudflare服务可能不支持自定义nonce，需要测试。

• 手动接管Cloudflare服务的加载逻辑
  对于邮件混淆这类服务，可以关闭Cloudflare的自动注入功能，手动生成混淆后的邮件代码（Cloudflare通常提供手动生成工具），然后将代码放到你自己已被CSP信任的脚本文件或内联脚本（需用哈希/nonce授权）中，这样就能绕过strict-dynamic的限制。
  对于Rocket Loader，若上述哈希方案无效，可尝试手动初始化Rocket Loader，将初始化代码放到可信脚本中，替代Cloudflare的自动注入。

• 临时放宽CSP（不推荐，仅作应急）
  若上述方法都无法快速落地，可临时在script-src中添加'unsafe-inline'和Cloudflare的相关域名（比如cdnjs.cloudflare.com、cloudflareinsights.com等），但这会降低CSP的安全性，可能抵消strict-dynamic带来的防护效果，仅建议在测试阶段使用，后续务必替换为更安全的方案。

内容的提问来源于stack exchange，提问作者dev