javascript - XMLHttpRequest无法加载XXX No'Access-Control-Allow-Origin' header

Question

tl; dr;关于同一原产地政策

我有一个Grunt进程，用于启动express.js服务器实例。直到现在，当它开始为空白页提供服务时，它的工作情况都非常好，在Chrome（最新版本）的开发人员控制台的错误日志中显示以下内容：


  XMLHttpRequest无法加载https://www.example.com/
      请求中没有'Access-Control-Allow-Origin'标头
      资源。因此，不允许访问源'http://localhost:4300'。


是什么阻止了我访问该页面？

Answer 1

tl; dr —答案的末尾有一个摘要，以使查找相关部分更加容易。建议您阅读所有内容，因为它提供了有用的背景知识，可帮助您理解为什么这样做的原因，从而使您更容易了解如何在不同情况下应用。

关于同一原产地政策

这是Same Origin Policy。它是浏览器实现的安全功能。

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

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

可以使用three characters演示表明需要SOP的标准方案：


爱丽丝是一个使用网络浏览器的人
鲍勃经营一个网站（在您的示例中为<iframe>）
Mallory运行一个网站（在您的示例中为https://www.[website].com/）


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

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

浏览器的同源策略禁止JavaScript读取Bob网站返回的数据（Bob和Alice不想让Mallory访问）。 （请注意，例如，您可以使用responseText元素在各个原点之间显示图像，因为图像的内容不会暴露在JavaScript（或Mallory）中……除非您将画布放入混合中，否则会生成一个同源冲突错误）。



为什么在您认为不应采用同一来源政策时

对于任何给定的URL，可能不需要SOP。在这种情况下，有两种常见的情况：


爱丽丝，鲍勃和马洛里是同一个人。
鲍勃（Bob）提供完全公开的信息


…但是浏览器无法知道以上两个条件是否成立，因此信任不是自动的，因此会应用SOP。在浏览器将数据提供给其他网站之前，必须明确授予权限。



为什么“相同来源策略”仅适用于网页中的JavaScript

浏览器扩展<img>，浏览器开发人员工具中的“网络”选项卡以及Postman等应用程序均为已安装的软件。他们并没有将数据从一个网站传递到属于另一个网站的JavaScript，这仅仅是因为您访问了另一个网站。安装软件通常需要更明智的选择。

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

*必须仔细编写浏览器扩展，以避免跨域问题。 See the Chrome documentation for example。



为什么不使用JS即可在页面中显示数据

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



CORS

错误消息中引用的<img> HTTP响应标头是CORS标准的一部分，该标准允许Bob显式授予对Mallory站点的访问权限，以通过Alice的浏览器访问数据。

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

Access-Control-Allow-Origin: *

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

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

…将仅允许特定站点访问它，而Bob可以基于Access-Control-Allow-Origin请求标头动态生成该消息，以允许多个但不是所有站点访问它。

Bob如何设置响应头的具体细节取决于Bob的HTTP服务器和/或服务器端编程语言。有a collection of guides for various common configurations可能会有所帮助。



注意：某些请求很复杂，并且会发送preflight OPTIONS请求，服务器必须先响应该请求，然后浏览器才会发送JS要发出的GET / POST / PUT /任何请求。仅将Origin添加到特定URL的CORS实现经常因此而被绊倒。



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


数据不是私人的或
马洛里受到信任




但是我不是鲍勃！

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

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



错误消息中提到“预检响应”

一些跨源请求是preflighted。

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


包括Cookie之类的凭据
无法使用常规HTML表单生成（例如，具有自定义标头或无法在表单的Access-Control-Allow-Origin中使用的Content-Type）。


如果您正确地做了一些需要预检的操作

在这种情况下，此答案的其余部分仍然适用，但是您还需要确保服务器可以侦听预检请求（将是enctype（而不是OPTIONS，GET或您尝试执行的任何操作）发送），并使用正确的POST标头以及正确的Access-Control-Allow-Origin和Access-Control-Allow-Methods进行响应，以允许您使用特定的HTTP方法或标头。

如果您误触发了预检

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

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


尝试在请求上放置Access-Control-Allow-Headers和其他CORS响应标头。这些不属于请求，对您没有任何帮助（可以授予权限的权限系统的意义是什么？），并且必须仅出现在响应中。
尝试将Access-Control-Allow-Origin标头放在没有请求主体来描述其内容的GET请求上（通常在作者混淆Content-Type: application/json和Content-Type时）。


在这两种情况下，删除多余的请求标头通常足以避免进行预检（与支持简单请求但不预检请求的API通信时，将解决此问题）。



不透明的回应

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

如果使用的是the Accept API（而不是fetch），则可以将其配置为不尝试使用CORS。

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

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

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


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


从而：

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

替代CORS

JSONP

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

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

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

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

由于JSONP通过添加Access-Control-Allow-Origin元素以JavaScript程序的形式加载数据而工作，该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请求时失败）。

具有本地开发服务器的适当开发环境
通常是更好的方法。



其他安全风险

请注意，SOP / CORS不会缓解需要单独处理的XSS，CSRF或SQL Injection攻击。



摘要


您无法在客户端代码中执行任何操作来使CORS访问其他人的服务器。
如果控制服务器，则将请求发送至：向其添加CORS权限。
如果您与控制它的人友好：让他们为它添加CORS权限。
如果是公共服务：


阅读他们的API文档，以了解他们对使用客户端JavaScript访问它的看法：


他们可能会告诉您使用特定的网址
他们可能支持JSONP
他们可能根本不支持来自客户端代码的跨域访问（这可能是出于安全原因的故意决定，尤其是如果您必须在每个请求中传递个性化的API密钥时）。

确保您不会触发不需要的预检请求。 API可能会授予简单请求的权限，但不会授予预检请求的权限。

如果上述方法均不适用：请让浏览器与您的服务器通信，然后让您的服务器从另一台服务器获取数据并继续传递。 （还有一些第三方托管服务，它们将CORS标头附加到您可以使用的可公开访问的资源上）。