About the Same Origin Policy

这是“ 同源政策”。它是浏览器实现的安全功能。

你的特殊情况显示了如何为XMLHttpRequest实现它（如果使用fetch，你将获得相同的结果），但它也适用于其他内容（例如，将图像加载到<canvas>或将文档加载到<iframe>），略有不同的实现。

（很奇怪，它也适用于CSS字体，但这是因为铸造厂坚持使用DRM，而不是出于Same Origin Policy通常涵盖的安全性问题）。

证明需要SOP的标准方案可以用三个字符来证明：

• 爱丽丝是一个使用网络浏览器的人
• 鲍勃经营一个网站（https://www.[website].com/在你的示例中）
• Mallory经营一个网站（http://localhost:4300在你的示例中）

爱丽丝已登录到鲍勃的网站，并且那里有一些机密数据。可能是公司的Intranet（仅可通过LAN上的浏览器访问）或她的在线银行（仅可通过输入用户名和密码后获得的cookie进行访问）。

爱丽丝访问了Mallory的网站，该网站具有一些JavaScript，这些JavaScript导致爱丽丝的浏览器向鲍勃的网站发出HTTP请求（从她的IP地址，她的cookie等）。这可能与使用XMLHttpRequest和阅读一样简单responseText。

浏览器的同源策略禁止JavaScript读取Bob网站返回的数据（Bob和Alice不想让Mallory访问）。（请注意，例如，你可以使用<img>跨原点的元素来显示图像，因为图像的内容不会暴露给JavaScript（或Mallory）……除非将画布放入混合中，否则会产生相同的来源违反错误）。

为什么在你认为不应采用同一来源政策时
对于任何给定的URL，可能不需要SOP。在这种情况下，有两种常见的情况：

爱丽丝，鲍勃和马洛里是同一个人。
鲍勃（Bob）提供完全公开的信息
…但是浏览器无法知道以上两个条件是否成立，因此信任不是自动的，因此会应用SOP。在浏览器将数据提供给其他网站之前，必须明确授予权限。

为什么“相同来源策略”仅适用于网页中的JavaScript
浏览器扩展*，浏览器开发人员工具中的“网络”选项卡以及Postman等应用程序都是已安装的软件。他们不会因为你访问另一个网站而将数据从一个网站传递到属于不同网站的JavaScript中。安装软件通常需要更明智的选择。

没有第三方（Mallory）被视为风险。

*浏览器扩展确实需要仔细编写，以避免跨域问题。例如，请参阅Chrome文档。

为什么不使用JS即可在页面中显示数据
在许多情况下，Mallory的网站可能导致浏览器从第三方获取数据并显示（例如，通过添加元素来显示图像）。不过，Mallory的JavaScript不可能读取该资源中的数据，只有Alice的浏览器和Bob的服务器可以做到这一点，因此它仍然是安全的。

CORS
错误消息中提到的Access-Control-Allow-OriginHTTP 响应标头是CORS标准的一部分，该标准允许Bob显式授予Mallory站点的权限以通过Alice的浏览器访问数据。

一个基本的实现将只包括：

Access-Control-Allow-Origin: *

…在响应标题中，以允许任何网站读取数据。

Access-Control-Allow-Origin: http://example.com/

…将仅允许特定站点访问它，而Bob可以根据Origin 请求标头动态生成该消息，以允许多个但不是全部站点访问它。

Bob如何设置响应头的具体细节取决于Bob的HTTP服务器和/或服务器端编程语言。提供了一些可能有用的各种常见配置的指南。

适用于CORS规则的模型

注意：有些请求很复杂，并且会发送一个服务器必须响应的预检 OPTIONS请求，然后浏览器才发送JS想要发出的GET / POST / PUT /任何请求。仅添加Access-Control-Allow-Origin到特定URL 的CORS实施常常因此而被绊倒。

显然，通过CORS授予许可是Bob只会在以下情况之一时执行的操作：

• The data was not private or
• Mallory was trusted

But I’m not Bob!

Mallory没有添加此标头的标准机制，因为它必须来自Bob不能控制的Bob的网站。

如果Bob正在运行公共API，则可能存在一种机制，可以打开CORS（也许通过以某种方式格式化请求，或者在登录到Bob站点的开发人员门户站点之后使用config选项）。不过，这必须是Bob实施的一种机制。Mallory可以阅读Bob的站点上的文档以查看是否有可用的东西，或者她可以与Bob交谈并要求他实施CORS。

错误消息中提到“预检响应”
一些跨源请求已经过时。

在粗略地说，你尝试发出跨域请求时会发生这种情况：

包括Cookie之类的凭据
无法使用常规的HTML表单生成（例如，具有自定义标头或你不能在表单的中使用的Content-Type enctype）。
如果你正确地做了一些需要预检的操作
在这些情况下，此答案的其余部分仍然适用，但是你还需要确保服务器可以侦听预检请求（将是OPTIONS（而不是GET，POST或者你尝试发送的任何内容）并以正确的方式对其进行响应Access-Control-Allow-Origin包头，而且Access-Control-Allow-Methods并Access-Control-Allow-Headers允许特定HTTP方法或标题。

如果你误触发了预检

有时人们在尝试构建Ajax请求时会犯错误，而有时会触发预检。如果API旨在允许跨域请求，但不需要任何需要进行预检的内容，则这可能会中断访问。

触发此错误的常见错误包括：

尝试Access-Control-Allow-Origin在请求上放置其他CORS响应标头。这些不属于请求，对你没有任何帮助（可以授予权限的权限系统的意义是什么？），并且必须仅出现在响应中。
尝试Content-Type: application/json在没有请求主体的GET请求上放置标头来描述的内容（通常在作者Content-Type与和混淆时Accept）。
在这两种情况下，删除多余的请求标头通常足以避免进行预检（与支持简单请求但不预检请求的API通信时，将解决此问题）。

不透明的回应

有时你需要发出HTTP请求，但不需要读取响应。例如，如果要将日志消息发布到服务器进行记录。

如果你使用的是fetchAPI（而不是XMLHttpRequest），则可以将其配置为不尝试使用CORS。

请注意，这不会让你执行需要CORS执行的任何操作。你将无法阅读回复。你将无法发出需要进行预检的请求。

它将使你发出简单的请求，看不到响应，也不会在错误消息中填充开发人员控制台。

当你使用进行请求fetch且没有获得使用CORS查看响应的权限时，Chrome给出了Chrome错误消息，说明了如何执行此操作：

CORS策略已阻止https://example.com/从“来源” 获取“ ”的访问https://example.net：Access-Control-Allow-Origin请求的资源上不存在“ ”头。如果不透明的响应满足你的需求，请将请求的模式设置为“ no-cors”，以在禁用CORS的情况下获取资源。

从而：

fetch("http://example.com", { mode: "no-cors" }

替代CORS

JSONP
鲍勃还可以使用JSONP之类的黑客提供数据，这是人们在CORS出现之前对Ajax进行跨源编程的方式。

它通过以JavaScript程序的形式显示数据来工作，该程序将数据注入到Mallory的页面中。

它要求Mallory信任Bob不要提供恶意代码。

请注意一个共同的主题：提供数据的站点必须告诉浏览器，第三方站点可以访问它发送给浏览器的数据。

由于JSONP通过<script>以调用程序已在页面中的函数的JavaScript程序的形式附加元素来加载数据而工作，因此尝试在返回JSON的URL上使用JSONP技术将失败—通常会出现CORB错误—因为JSON不是JavaScript。

将两个资源移动到一个原始位置
如果运行JS的HTML文档和所请求的URL来自同一来源（共享相同的方案，主机名和端口），则默认情况下，它们的Same Origin Policy会授予权限。不需要CORS。

代理人
Mallory 可以使用服务器端代码来获取数据（然后可以照常通过HTTP将其从服务器传递到Alice的浏览器）。

它将：

• 添加CORS头
• 将响应转换为JSONP
• 与HTML文档起源相同
  该服务器端代码可以由第三方（例如CORS Anywhere）编写和托管。请注意以下方面的隐私含义：第三方可以监视谁代理其服务器上的内容。

鲍勃不需要为此授予任何权限。

很好，因为那只是在马洛里和鲍勃之间。鲍勃无法认为马洛里是爱丽丝，也无法向马洛里提供应在爱丽丝和鲍勃之间保密的数据。

因此，Mallory只能使用此技术读取公共数据。

编写Web应用程序以外的内容
如“为什么同一来源策略仅适用于网页中的JavaScript”部分所述，你可以通过不在网页中编写JavaScript来避免SOP。

这并不意味着你不能继续使用JavaScript和HTML，而是可以使用其他某种机制来分发它，例如Node-WebKit或PhoneGap。

浏览器扩展
应用相同来源策略之前，浏览器扩展可能会在响应中注入CORS标头。

这些对开发很有用，但对生产站点却不切实际（要求站点的每个用户安装禁用其浏览器安全功能的浏览器扩展都是不合理的）。

它们也往往只适用于简单的请求（处理预检OPTIONS请求时失败）。

通常，使用本地开发服务器使用适当的开发环境是一种更好的方法。