为何CSP会拦截已明确允许的脚本文件？

我负责的应用近期针对脚本元素启用了更严格的内容安全策略（CSP），基于Express使用helmet包的配置如下：

module.exports = helmet({
  contentSecurityPolicy: {
    reportOnly: false,
    useDefaults: false,
    directives: {
      "report-uri": "/api/csp-violation-report",
      "script-src": [
        "'self'",
        "'report-sample'",
        // 其他允许的域名...
        "https://connect-cdn.atl-paas.net/all.js", // 重点允许的脚本
        // 更多源...
        (req, res) => `'nonce-${res.locals.nonce}'`,
      ],
      "default-src": "* 'unsafe-inline' data: blob:",
    }
  }
})

配置逻辑为：仅允许从特定源加载脚本（包含Atlassian的https://connect-cdn.atl-paas.net/all.js），或通过指定nonce加载内联脚本；同时设置浏览器将CSP违规报告提交到指定地址，报告经筛选后写入日志以便排查。

今日收到一份异常违规报告：

{
  "blocked-uri": "https://connect-cdn.atl-paas.net/all.js",
  "document-uri": "[已脱敏]",
  "effective-directive": "script-src-elem",
  "original-policy": "report-uri /api/csp-violation-report;script-src 'self' 'report-sample' [已脱敏] https://connect-cdn.atl-paas.net/all.js [已脱敏] 'nonce-xxxxx';default-src * 'unsafe-inline' data: blob:",
  "script-sample": "",
  "violated-directive": "script-src-elem"
}

令人困惑的是，被拦截的URI是已明确允许的脚本，且报告中的original-policy也包含该源，仅极少数用户出现此情况，无固定浏览器特征。以下是针对疑问的排查分析：

1. 该报告是否代表用户端真的存在功能异常？ #

不一定。CSP违规报告的触发分两种场景：一是脚本确实被拦截导致功能失效，二是报告生成但脚本实际被允许（比如浏览器中间处理逻辑的偏差）。如果没有用户反馈对应功能异常，大概率只是报告层面的问题，而非实际功能故障——极少数用户的情况可能是临时网络异常或浏览器状态问题导致的单次触发。

2. 是否存在浏览器误报的可能？ #

存在，常见场景包括：

• 旧CSP规则缓存：用户浏览器缓存了此前未允许该脚本的旧策略，加载时触发旧规则的报告，但实际新规则已生效。
• 浏览器扩展干扰：广告拦截、隐私类扩展可能修改请求或篡改CSP规则，导致误判并提交报告。
• 版本兼容性问题：部分老旧浏览器对script-src-elem这类较新指令的支持不完善，可能出现规则匹配错误。

3. 配置是否存在疏漏？ #

需重点检查以下几点：

• 规则匹配精度问题：当前配置的是完整脚本URL https://connect-cdn.atl-paas.net/all.js，若实际请求的URL带有查询参数（如https://connect-cdn.atl-paas.net/all.js?v=1.0），部分浏览器会判定为不同URL触发拦截。可将规则调整为域名级允许https://connect-cdn.atl-paas.net，或允许带参数的路径。
• 指令优先级问题：script-src-elem是专门针对脚本元素的指令，虽然script-src会作为其 fallback，但部分浏览器处理时可能存在优先级逻辑偏差。建议直接添加script-src-elem指令，配置与script-src一致的规则。
• nonce生成偶发错误：若nonce生成逻辑存在单次故障，导致请求nonce与CSP中的nonce不匹配，可能连带触发其他脚本误报，但这种情况通常会伴随更多相关报告，而非仅针对Atlassian脚本。

4. 是否为恶意提交？ #

可能性较低，但可通过以下方式排查：

• 检查报告的请求来源IP是否集中，是否存在异常请求频率。
• 查看document-uri对应的页面是否有爬虫、自动化工具等异常访问痕迹。

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