在实现 csp-header 时，我将我的策略指定为：default-src 'self'; script-src www.gstatic.com;由于我还没有声明script-src-elem我的 CSP 政策中的指令，如中所述this https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src-elemmdn 文档，我期望定义策略script-src用于script-src-elem指令也是如此。但是，我看到违规行为被报告为"violated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah".
知道为什么会发生这种行为吗？
在我的一些应用程序中看到完全相同的模式后，我终于找到了问题的根源！
我们看到的奇怪之处是，CSP 报告的主机名是确实 in the script-src指示;我们知道script-src-elem应该回到这些指令。从这个角度来看，这些报道实际上是不可能发生的。
我们发现以下内容：这些报告的来源用户正在使用隐私獾 https://privacybadger.org/浏览器扩展，导致其阻止的主机 (Google) 出现误报 CSP 报告。我没有深入研究它，但这是我关于这是如何发生的理论：
- 内容安全策略执行预请求检查 https://www.w3.org/TR/CSP3/#style-src-pre-request用于页面上包含的 JavaScript（例如 gstatic.com 或 google-analytics.com）。预请求检查通过，因为该主机名在策略中是允许的。
- 浏览器发起资源请求
- PrivacyBadger 通过浏览器的 onBeforeRequest API 拦截请求（请参阅隐私獾来源 https://github.com/EFForg/privacybadger/blob/master/src/js/webrequest.js#L47 and Chrome 文档 https://developer.chrome.com/extensions/webRequest#event-onBeforeRequest)
- ProvacyBadger 返回一个代理数据块 https://github.com/EFForg/privacybadger/blob/625a7fdf88c85e693582a802c82326c4a3d50e14/src/js/surrogates.js#L74对于资产。这样做是为了确保代码依赖于真正的 javascript（例如
window.ga）不会破坏。
- 然后浏览器执行请求后检查 https://www.w3.org/TR/CSP3/#script-src-post-request针对返回的 base64 blob
- 请求后检查失败 - 因为策略不允许
data: for script-src
- 浏览器发送被阻止资产的 CSP 报告。
这看起来可能是一个浏览器错误 - 因为report反映原始资产的第三方主机名；而被阻止的内容实际上是data:通过拦截的请求返回的 blob。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
