为什么 script-src-elem 不使用来自 script-src 的值作为后备？

Question

在实现 csp-header 时，我已将我的策略指定为： default-src 'self'; script-src www.gstatic.com;由于我没有script-src-elem在我的 csp 策略中声明指令，如本mdn 文档中所述，我期望定义的策略也script-src用于script-src-elem指令。但是，我看到违规被报告为"viloated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah"。

知道为什么会发生这种行为吗？

Answer 1

在我的一些应用程序中看到这种完全相同的模式后，我终于找到了它的根源！

我们看到的奇怪之处在于，CSP 报告中的主机名肯定在script-src指令中；我们知道这script-src-elem应该回到这些指令。从这个角度来看，这些报告应该几乎不可能发生。

我们发现：这些报告来自的用户正在使用PrivacyBadger浏览器扩展程序，这导致其阻止的主机 (Google) 出现误报 CSP 报告。我没有深入研究它，但这是我关于如何发生的理论：

1. 内容安全策略对页面上的 JavaScript执行请求前检查（例如 gstatic.com 或 google-analytics.com）。请求前检查通过，因为策略中允许使用主机名。
2. 浏览器发起资源请求
3. PrivacyBadger 通过浏览器的 onBeforeRequest API 拦截请求（参见PrivacyBadger 源码和Chrome 文档）
4. ProvacyBadger 返回资产的代理数据 blob。它这样做是为了确保依赖于真实 javascript（例如window.ga）的代码不会中断。
5. 然后浏览器对返回的 base64 blob执行请求后检查
6. 该请求后检查失败-因为政策不允许data:的script-src
7. 浏览器发送被阻止资产的 CSP 报告。

这似乎是浏览器的错误——因为报告反映了原始资产的第三方主机名；而被阻止的内容实际上data:是通过拦截的请求返回的blob。

Answer 2

从您链接到的文档中：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src-elem

HTTP Content-Security-Policy (CSP) script-src-elem 指令指定 JavaScript 元素的有效源，但不指定 onclick 等内联脚本事件处理程序。

如果没有看到代码的其余部分，可以安全地假设您看到此错误是内联事件处理程序的结果，并且需要script-src-elem在 CSP 策略中进行定义。