ASP.NET应用经Cloudflare时首次加载首页出现CSP指令违规问题排查

为什么首次加载拦截，后续返回正常？ #

Cloudflare的安全优化和缓存机制是核心原因：

• 首次访问时，Cloudflare处于冷缓存状态，会实时对首页HTML做优化处理（比如自动压缩内联脚本、启用Rocket Loader重构脚本加载逻辑），这会改变页面内联脚本的内容或结构。而Cloudflare自动生成的CSP规则里的哈希是基于原始页面的内联脚本，优化后的脚本哈希和CSP规则不匹配，浏览器就会触发拦截。
• 当导航到其他页面再返回首页时，浏览器或Cloudflare的缓存已经存储了处理后的页面版本，此时Cloudflare直接返回缓存内容，不会重新修改内联脚本，哈希和CSP规则匹配，所以不再拦截。
• 如果绕开Cloudflare，没有这些实时优化和CSP注入，自然不会出现哈希不匹配的问题。

不用unsafe-inline的JS处理方案 #

1. 给内联脚本添加匹配的哈希 #

• 从浏览器控制台的报错信息里，复制系统给出的内联脚本正确哈希（就是报错里的sha256-....字符串），把它添加到Cloudflare CSP规则的script-src指令中。
• 注意：如果Cloudflare开了自动Minify，内联脚本会被压缩，原始脚本的哈希会失效。这种情况要么关闭Minify，要么重新计算压缩后脚本的哈希（可以用本地命令行或在线工具生成），再更新到CSP规则里。部分Cloudflare套餐支持自动生成压缩后脚本的哈希，也可以开启这个功能。

2. 使用Nonce随机数 #

• 在ASP.NET后端每次请求时生成一个唯一的Base64格式Nonce值，比如：

  var nonce = Convert.ToBase64String(Guid.NewGuid().ToByteArray());
  ViewBag.Nonce = nonce;
  

• 在页面的内联脚本标签上添加nonce属性：

  <script nonce="@ViewBag.Nonce">
    // 你的内联脚本内容
  </script>
  

• 同时在ASP.NET中通过响应头动态设置CSP（替代Cloudflare的静态CSP配置），确保每次请求的Nonce都能同步到script-src指令中，格式为'nonce-你的Nonce值'，避免缓存导致的Nonce失效。

额外的Cloudflare配置检查 #

• 临时关闭Rocket Loader：这个功能会重构脚本加载逻辑，很容易导致内联脚本的CSP哈希不匹配。如果关闭后问题解决，再调整Rocket Loader的精细配置（比如排除特定内联脚本）。
• 检查Cloudflare的CSP生成器：如果用了自动生成CSP的功能，它可能漏识别了页面中的内联脚本，需要手动补充哈希或Nonce规则。

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