内容安全政策和相同的原始政策 [英] Content Security Policy and same origin policy

问题描述

MDN在内容安全政策方面表示：

MDN says in relation to Content Security Policy that:

如果网站不提供CSP标头，浏览器同样使用
标准同源政策。

If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

我的网站没有定义任何CSP标题，仍然允许从谷歌，adobe等加载脚本。这与MDN上述声明有什么关系？如果相同的原始策略是默认的，那么来自外部源的脚本如何被允许执行？

My website doesn't define any CSP headers and still allows scripts to be loaded from google, adobe etc. How is this possible in relation to the statement by MDN above? If same origin policy is the default how are scripts from external sources allowed to execute?

推荐答案

我的网站没有定义任何CSP标题，仍然允许从谷歌，adobe等加载脚本。这与上述MDN的声明有什么关系？

My website doesn't define any CSP headers and still allows scripts to be loaded from google, adobe etc. How is this possible in relation to the statement by MDN above?

这是由于MDN中记录的其他详细信息：

That’s due to other details documented in MDN here:

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

...特别是，这一部分：

…in particular, this part:

跨源嵌入通常是允许的。示例如下所示。

Cross-origin embedding is typically allowed. Examples are listed below.

• 带的JavaScript< script src =...>< /脚本> 。语法错误的错误消息仅适用于同源脚本。


• 带有的CSS< link rel =stylesheethref =...> 。


• 图片< img> 。


• 媒体文件< video> 和< audio> 。


• 插件包含< object> ，< embed> 和< applet> 。


• 字体 @ font-face 。有些浏览器允许跨源字体，有些浏览器需要同源字体。


• 任何< frame> 和< IFRAME> 。网站可以使用 X-Frame-Options 标头来阻止这种形式的跨域交互。

• JavaScript with <script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
• CSS with <link rel="stylesheet" href="...">.
• Images with <img>.
• Media files with <video> and <audio>.
• Plug-ins with <object>, <embed> and <applet>.
• Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
• Anything with <frame> and <iframe>. A site can use the X-Frame-Options header to prevent this form of cross-origin interaction.

在开始遇到的安全漏洞启用之前，大多数都被添加到平台上（允许跨源嵌入）。所以我想如果我们都已经完成并且可以从头开始重新设计，他们默认不允许跨源嵌入。

Most of those were added to the platform that way (allowing cross-origin embedding) before the security exploits enabled by doing that had started to be encountered. So I guess if we all had it to over and could redesign from scratch, they’d instead by default disallow cross-origin embedding.

但不幸的是现实是我们现在仍然坚持使用它们 - 因为如果我们现在要更改默认的跨源嵌入行为，它将打破过去20多年来创建的无数现有网站的行为。

But unfortunately instead the reality is that we’re now stuck with them as-is — because if we were to change that default cross-origin-embedding behavior now, it’d break the behavior of countless existing sites that have been created over the last 20+ years.

就CSP而言，如果默认情况下这些元素不允许跨源嵌入，那么CSP所做的很大一部分都不是必需的（尽管不允许使用内联脚本和样式的CSP部分，以及禁止 eval 的方面。

And as far as CSP goes, if those elements didn’t allow cross-origin embedding by default, then a large part of what CSP does wouldn’t be necessary (though the parts of CSP that disallow inline script and style still would be, as well as the aspect of disallowing eval).

鉴于这一切，我想另一种描述同源策略的方法是它基本上适用于脚本化 JavaScript发起的跨源请求（即发起的请求）通过XHR或Fetch API而不是 markup-init iated 请求（即由HTML元素发起的请求）。

Given all that, I guess another way of describing the same-origin policy is that it basically applies to scripted JavaScript-initiated cross-origin requests (that is, requests initiated through XHR or the Fetch API) rather than to markup-initiated requests (that is, requests initiated by HTML elements).

这是一个过于简单化但无论如何在跨域嵌入的背后有一些逻辑背后的逻辑资源不会带来与非预期权限升级相同级别的风险，并且允许跨域脚本编写。

That’s an oversimplification but anyway there is some logic behind that distinction in that cross-origin embedding of a resource doesn’t carry the same level of risk of unintended privilege escalation and such that comes with allowing cross-origin scripting.

这篇关于内容安全政策和相同的原始政策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！