XMLHttpRequest 无法加载 XXX 否“Access-Control-Allow-Origin”标头

Question

太长；博士；关于同源策略

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

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

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

Answer 1

tl;dr — 当您想要（主要）使用客户端 JS 从不同的服务器读取数据时，您需要包含数据的服务器向需要数据的代码授予显式权限。

最后有一个摘要，答案中有标题，以便更容易找到相关部分。不过，建议阅读所有内容，因为它为理解原因提供了有用的背景，使了解如何在不同情况下如何应用变得更容易。

关于同源策略

这是同源策略 。它是浏览器实现的一项安全功能。

您的特定案例显示了它是如何为 XMLHttpRequest 实现的（如果您使用 fetch，您将获得相同的结果），但它也适用于其他事物（例如加载到 或加载到 中的文档），只是实现方式略有不同。

证明 SOP 需求的标准场景可以用三个角色来演示：

• Alice 是一个人使用网络浏览器
• Bob 运行一个网站（在您的示例中为 https://www.example.com/）
• Mallory 运行一个网站（http://localhost:4300 在你的例子）

爱丽丝登录到鲍勃的网站并且那里有一些机密数据。也许是公司内部网（只能通过 LAN 上的浏览​​器访问），或者她的网上银行（只能通过输入用户名和密码后获得的 cookie 访问）。

Alice 访问 Mallory 的网站，该网站包含一些 JavaScript，导致 Alice 的浏览器向 Bob 的网站发出 HTTP 请求（通过她的 IP 地址和 cookie 等）。这可以像使用 XMLHttpRequest 并读取 responseText 一样简单。

浏览器的同源策略阻止 JavaScript 读取 Bob 网站返回的数据（Bob 和 Alice 不希望 Mallory 访问该网站）。 （请注意，例如，您可以跨源使用 元素显示图像，因为图像的内容不会暴露给 JavaScript（或 Mallory）……除非您将 canvas 放入混合，在这种情况下您将生成同源违规错误）。

---

为什么同源策略适用，而您认为它不应该适用

对于任何给定的 URL，可能不需要 SOP。这种情况的几个常见场景是：

• Alice、Bob 和 Mallory 是同一个人。
• Bob 提供的是完全公开的信息

……但是浏览器无法知道上述任一信息是否属实，因此信任不是自动的，并且应用了 SOP。在浏览器将从 Bob 收到的数据提供给其他网站之前，必须明确授予许可。

---

为什么同源策略适用于网页中的 JavaScript，但

在网页之外

几乎不适用浏览器扩展*、浏览器开发人员工具中的“网络”选项卡以及 Postman 等应用程序都是安装软件。它们不会仅仅因为您访问了另一个网站就将数据从一个网站传递到属于另一网站的 JavaScript。。安装软件通常需要更明智的选择。

不存在被视为风险的第三方（马洛里）。

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

网页内部

大多数时候，仅在网页上显示某些内容时不会有大量信息泄露。

如果您使用 元素加载图像，则该图像会显示在页面上，但向 Mallory 暴露的信息很少。 JavaScript 无法读取图像（除非您使用 crossOrigin 属性通过 CORS 显式启用请求权限），然后将其复制到她的服务器。

也就是说，一些信息确实泄露了，引用 Domenic Denicola（Google 的）：

网络的基本安全模型是同源策略。我们
在该安全之前，该规则有几个遗留的例外情况
模型已经就位，脚本标签是最令人震惊的标签之一
并且最危险。 （请参阅各种“JSONP”攻击。）

许多年前，也许随着 XHR 或网络字体的引入（我
记不清了），我们在沙子上画了一条线，并说没有新的
Web 平台功能将打破同源政策。现有的
功能需要继承并经过精心打磨
以及经常被利用的异常，为了不破坏网络，
但我们当然不能在我们的安全策略中添加更多漏洞。

这就是为什么您需要 CORS 权限才能跨源加载字体。

---

为什么无需使用 JS 读取数据即可在页面上显示数据

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

---

CORS

错误消息中引用的 Access-Control-Allow-Origin HTTP response 标头是 CORS 标准，允许 Bob 明确授予 Mallory 网站通过 Alice 浏览器访问数据的权限。

基本的实现只包括：

Access-Control-Allow-Origin: *

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

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

…将只允许特定站点访问它，Bob 可以根据 Origin 请求 标头动态生成它，以允许多个（但不是所有）站点访问它。

Bob 设置响应标头的具体情况取决于 Bob 的 HTTP 服务器和/或服务器端编程语言。 Node.js/Express.js 的用户应使用文档完善的 CORS 中间件。其他平台的用户应该看看各种常见配置的指南集合，这可能会有所帮助。

注意：某些请求很复杂，会发送 预检 选项请求，服务器必须在浏览器将发送 JS 想要发出的 GET/POST/PUT/Whatever 请求。仅将 Access-Control-Allow-Origin 添加到特定 URL 的 CORS 实现通常会因此而出错。

---

显然，只有在以下情况下，Bob 才会通过 CORS 授予权限：

• 数据不是私有的或
• Mallory 受信任

---

如何添加这些标头？

这取决于您的服务器端环境。

如果可以的话，请使用专门用于处理 CORS 的库，因为它们将为您提供简单的选项，而不必手动处理所有内容。

Enable-Cors.org 提供了您可能会觉得有用的特定平台和框架的文档列表。

但我不是鲍勃！

Mallory 没有标准机制来添加此标头，因为它必须来自 Bob 的网站，而她无法控制该网站。

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

---

提及“预检响应”的错误消息

某些跨源请求是 预检。

当（粗略地说）您尝试发出以下跨域请求时，就会发生这种情况：

• 包含 cookie 之类的凭据
• 无法使用常规 HTML 表单生成（例如，设置了无法在表单的 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和接受）。

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

---

不透明响应（no-cors 模式）

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

如果您使用fetch API< /a> （而不是 XMLHttpRequest），那么您可以将其配置为不尝试使用 CORS。

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

它可以让您发出简单的请求，而不会看到响应，并且不会在开发人员控制台中填充错误消息。

当您使用 fetch 发出请求并且没有获得使用 CORS 查看响应的权限时，Chrome 会给出错误消息，解释了具体操作方法：

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

因此：

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

---

CORS

JSONP

的替代方案Bob 还可以使用 JSONP 之类的 hack 来提供数据这就是 CORS 出现之前人们进行跨源 Ajax 的方式。

它的工作原理是以 JavaScript 程序的形式呈现数据，并将数据注入 Mallory 的页面。

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

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

由于 JSONP 的工作原理是附加一个

将两个资源移动到一个源

如果 JS 运行的 HTML 文档和所请求的 URL 位于同一源（共享相同的方案、主机名和端口），则同源策略默认授予权限。不需要 CORS。

代理

Mallory可以使用服务器端代码来获取数据（然后她可以像往常一样通过 HTTP 将数据从她的服务器传递到 Alice 的浏览器）。

它将：

• 添加 CORS 标头
• 将响应转换为
• 与 HTML 文档同源的

JSONP可以编写服务器端代码由第三方（例如 CORS Anywhere）托管。请注意这对隐私的影响：第三方可以监控谁在其服务器上代理了什么。

鲍勃不需要授予任何权限即可发生这种情况。

这里不存在任何安全隐患，因为这只是 Mallory 和 Bob 之间的事情。 Bob 无法认为 Mallory 是 Alice，也无法向 Mallory 提供应在 Alice 和 Bob 之间保密的数据。

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

但请注意，从他人网站获取内容并自行展示可能会侵犯版权，并使您面临法律诉讼。

编写 Web 应用程序以外的内容

正如“为什么同源策略仅适用于网页中的 JavaScript”部分所述，您可以通过不在网页中编写 JavaScript 来避免 SOP。

这并不意味着您不能继续使用 JavaScript 和 HTML，但您可以使用其他一些机制（例如 Node-WebKit 或 PhoneGap）来分发它。

浏览器扩展

浏览器扩展可以在应用同源策略之前在响应中注入 CORS 标头。

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

它们也往往只处理简单的请求（在处理预检选项请求时失败）。

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

---

其他安全风险

请注意，SOP / CORS 不能缓解 XSS、CSRF，或 SQL注入攻击，需要独立处理。

---

摘要

• 您在您的客户端代码中无法执行任何操作来启用对其他人服务器的CORS 访问。
• 如果您控制服务器，则会发出请求：向其添加 CORS 权限。
• 如果您与控制它的人很友好：让他们为其添加 CORS 权限。
• 如果它是一项公共服务（请记住，大多数第三方 API 设计为仅通过服务器端代码进行交互，并且不支持 CORS，但对于支持 CORS 的 API 除外）：
  • 阅读他们的 API 文档，了解他们如何使用客户端 JavaScript 访问它：
    • 他们可能会告诉您使用特定的网址
    • 他们可能支持 JSONP 而不是 CORS
    • 它们可能根本不支持客户端代码的跨源访问（这可能是出于安全考虑而做出的故意决定，特别是当您必须在每个请求中传递个性化 API 密钥时）。
  • 确保您没有触发不需要的预检请求。 API 可能会授予简单请求的权限，但不会授予预检请求的权限。
• 如果上述情况都不适用：让浏览器与您的服务器通信，然后让您的服务器从其他服务器获取数据并将其传递。 （还有第三方托管服务将 CORS 标头附加到您可以使用的可公开访问的资源）。

Answer 2

目标服务器必须允许跨源请求。为了允许它通过express，只需处理http选项请求：

app.options('/url...', function(req, res, next){
   res.header('Access-Control-Allow-Origin', "*");
   res.header('Access-Control-Allow-Methods', 'POST');
   res.header("Access-Control-Allow-Headers", "accept, content-type");
   res.header("Access-Control-Max-Age", "1728000");
   return res.sendStatus(200);
});

Answer 3

因为在接受的答案中没有提到这一点。

• 这个问题的情况并非如此，但可能会帮助其他人搜索该问题。
• 您可以在客户端代码中执行此操作，以防止某些情况下出现 CORS 错误。

您可以使用简单请求。
为了执行“简单请求”，请求需要满足几个条件。例如只允许 POST、GET 和 HEAD 方法，以及只允许某些给定的 headers（您可以找到所有条件 此处）。

如果您的客户端代码没有在请求中使用固定值显式设置受影响的标头（例如“接受”），则可能会出现某些客户端使用某些“非标准”值自动设置这些标头的情况，从而导致服务器不接受它作为简单请求 - 这会给你一个 CORS 错误。

Answer 4

这是由于 CORS 错误而发生的。 CORS 代表跨源资源共享。简而言之，当我们尝试从另一个域访问一个域/资源时，就会发生此错误。

在这里阅读更多相关信息：jquery 的 CORS 错误

要解决此问题，如果您有权访问其他域，您必须在服务器中允许 Access-Control-Allow-Origin。这可以添加到标题中。您可以为所有请求/域或特定域启用此功能。

如何获取跨域资源共享（CORS）发布请求工作

这些链接可能会有所帮助

Answer 5

这个 CORS 问题没有进一步阐述（由于其他原因）。

我目前因不同原因遇到此问题。
我的前端也返回“Access-Control-Allow-Origin”标头错误。

只是我指出了错误的 URL，因此该标头没有正确反映（我一直认为它确实反映了）。本地主机（前端）->调用非安全 http（应该是 https），请确保前端的 API 端点指向正确的协议。

Answer 6

我在 Chrome 控制台中遇到了同样的错误。

我的问题是，我尝试使用 http:// 而不是 https:// 访问该网站。因此没有什么需要修复的，只需使用 https 访问同一站点即可。

Answer 7

这个bug花了我2天时间。我检查了服务器日志，浏览器 Chrome/Edge 和服务器之间的预检选项请求/响应正常。主要原因是 XHTMLRequest 的 GET/POST/PUT/DELETE 服务器响应还必须具有以下标头：

access-control-allow-origin: origin  

“origin”位于请求标头中（浏览器将添加它为您提出要求）。例如：

Origin: http://localhost:4221

您可以添加如下响应标头以接受所有请求：

access-control-allow-origin: *  

或特定请求的响应标头，例如：

access-control-allow-origin: http://localhost:4221 

浏览器中的消息不清楚：“...请求的资源”

请注意：
CORS 对于本地主机来说效果很好。不同的端口意味着不同的域。
如果收到错误消息，请检查服务器端的 CORS 配置。

Answer 8

在大多数住房服务中，只需在目标服务器文件夹上的 .htaccess 中添加以下内容：

Header set Access-Control-Allow-Origin 'https://your.site.folder'

Answer 9

我有同样的问题。就我而言，我通过在 URL 中添加 timestamp 附加参数来修复此问题。即使我访问的服务器也不需要这样做。

示例 yoururl.com/yourdocument?timestamp=1234567

注意：我使用了 epos 时间戳

Answer 10

带有附加标头的“获取”请求转换为“选项”请求。所以Cors策略出现问题。您必须向您的服务器实施“选项”请求。 关于服务器端的 Cors 策略，您需要在服务器端允许 Cors 策略。 对于 Nodejs 服务器：详细信息

app.use(cors)

Java 与 Angular 集成：详细信息

@CrossOrigin(origins = "http://localhost:4200")

Answer 11

您应该启用 CORS 才能使其正常工作。