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

Question

在实现 csp-header 时，我已将我的策略指定为:default-src 'self'; script-src www.gstatic.com;由于我没有申报script-src-elem我的 csp 政策中的指令，如 this 中所述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 报告。我没有深入研究它，但这是我关于如何发生的理论:

内容安全策略执行 pre-request check对于 JavaScript 包含在页面上(例如 gstatic.com 或 google-analytics.com)。请求前检查通过，因为策略中允许使用主机名。

浏览器发起资源请求

PrivacyBadger 通过浏览器的 onBeforeRequest API 拦截请求(参见 PrivacyBadger source 和 Chrome documentation)

ProvacyBadger 返回 surrogate data blob为 Assets 。这样做是为了确保依赖于真正的 javascript(例如 window.ga)的代码不会中断。

然后浏览器执行 post-request check针对返回的 base64 blob

请求后检查失败 - 因为策略不允许 data:为 script-src

浏览器发送被阻止 Assets 的 CSP 报告。

这似乎是浏览器的错误——因为报告反射(reflect)了原始 Assets 的第三方主机名；而被屏蔽的内容实际上是 data:通过拦截的请求返回的 blob。