XMLHttpRequest无法加载XXX，没有'Access-Control-Allow-Origin'头部

Question

tl;dr;关于同源策略我有一个Grunt进程，它启动了一个express.js服务器的实例。直到刚才，这一切都运行得非常好，但现在它开始提供一个空白页面，并在Chrome（最新版本）的开发者控制台中的错误日志中显示以下内容：XMLHttpRequest无法加载https://www.example.com/请求的资源上没有'Access-Control-Allow-Origin'头。因此，不允许

P粉513316221 · Answer

目标服务器必须允许跨域请求。为了通过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);
});

P粉953231781 · Answer

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

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

关于同源政策

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

您的特殊情况显示了它是如何为 XMLHttpRequest 实现的（如果您使用 fetch，您将得到相同的结果），但它也适用于其他事物（例如加载到或加载到 </code> 中的文档），只是实现略有不同。</p> <p>演示 SOP 需求的标准场景可以用 <a href="https://en.wikipedia.org/wiki/Alice_and_Bob" rel="nofollow noreferrer">三个字符</a>:</p> 来演示 <ul> <li>Alice 是一个拥有网络浏览器的人</li> <li>Bob 运行一个网站（在您的示例中<code>https://www.example.com/</code>）</li> <li>Mallory 运行一个网站（在您的示例中<code>http://localhost:4300</code>）</li> </ul> <p>Alice 登录到 Bob 的网站并拥有一些机密数据。也许是公司内部网（只能通过 LAN 上的浏览器访问），或者她的网上银行（只能通过输入用户名和密码后获得的 cookie 访问）。</p> <p>Alice 访问 Mallory 的网站，该网站包含一些 JavaScript，导致 Alice 的浏览器向 Bob 的网站发出 HTTP 请求（通过她的 IP 地址和 cookie 等）。这可以像使用 <code>XMLHttpRequest</code> 并读取 <code>responseText</code>.</p> 一样简单 <p>浏览器的同源策略阻止 JavaScript 读取 Bob 网站返回的数据（Bob 和 Alice 不希望 Mallory 访问该网站）。（请注意，例如，您可以跨源使用 <code><img></code> 元素显示图像，因为图像的内容不会暴露给 JavaScript（或 Mallory）……除非您将画布放入其中在这种情况下，您<em>将</em>生成同源违规错误）。</p> <hr /> <h1>为什么同源策略适用，而你认为它不应该</h1> <p>对于任何给定的 URL，可能不需要 SOP。这种情况的一些常见场景是：</p><ul> <li>Alice、Bob 和 Mallory 是同一个人。</li> <li>Bob 正在提供完全公开的信息</li> </ul> <p>…但是浏览器无法知道上述任一情况是否属实，因此信任不是自动的，并且应用了 SOP。在浏览器将从 Bob 收到的数据提供给其他网站之前，必须明确授予权限。</p> <hr /> <h1>为什么同源策略适用于网页中的 JavaScript 而没有其他作用</h1> <h2>网页之外</h2> <p>浏览器扩展<code>*</code>、浏览器开发人员工具中的“网络”选项卡以及 Postman 等应用程序都是已安装的软件。他们不会将数据从一个网站传递到属于另一网站的 JavaScript <em> 只是因为您访问了该不同的网站</em>。安装软件通常需要更有意识的选择。</p> <p>不存在被视为风险的第三方（Mallory）。</p> <p>##*<code># 浏览器扩展确实需要仔细编写以避免跨源问题。 </code>请参阅 Chrome 文档作为示例<a href="https://www.chromium.org/Home/chromium-security/extension-content-script-fetches" rel="nofollow noreferrer">.</a> </p>网页内<h2> </h2>大多数时候，仅在网页上显示某些内容时不会有大量信息泄漏。<p> </p>如果您使用 <p><img><code> 元素来加载图像，那么它会显示在页面上，但向 Mallory 暴露的信息很少。 JavaScript 无法读取图像（除非您使用 </code>crossOrigin<code> 属性显式启用 CORS 请求权限），然后将其复制到她的服务器。</code> </p>也就是说，有些信息确实泄露了，<p>引用 Domenic Denicola（Google 的）<a href="https://github.com/whatwg/html/issues/1888#issuecomment-252999958" rel="nofollow noreferrer">:</a> </p>这就是为什么您需要 CORS 权限才能跨源加载字体。<p> </p> <hr />为什么用JS不用读取数据就能在页面显示数据<h1> </h1>在许多情况下，Mallory 的网站可能会导致浏览器从第三方获取数据并显示它（例如，通过添加 <p><img><code> 元素来显示图像）。 Mallory 的 JavaScript 不可能读取该资源中的数据，只有 Alice 的浏览器和 Bob 的服务器可以做到这一点，因此它仍然是安全的。</code> </p> <hr />CORS<h1> </h1>错误消息中引用的 <p>Access-Control-Allow-Origin<code> HTTP </code>response<strong> 标头是 </strong>CORS<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS" rel="nofollow noreferrer"> 标准的一部分，该标准允许 Bob 显式授予允许 Mallory 的网站通过 Alice 的浏览器访问数据。</a> </p>一个基本的实现只包括：<p> 雷雷 </p>...在响应标头中以允许任何网站读取数据。<p>雷雷 <p>… 只允许特定站点访问它，Bob 可以根据 <code>Origin</code> <em>request</em> 标头动态生成该标头，以允许多个（但不是全部）站点访问它.</p> <p>Bob 如何设置响应标头的细节取决于 Bob 的 HTTP 服务器和/或服务器端编程语言。 Node.js/Express.js 的用户应该使用<a href="https://www.npmjs.com/package/cors" rel="nofollow noreferrer">记录良好的 CORS 中间件</a>。其他平台的用户应该看看这个 <a href="https://enable-cors.org/server.html" rel="nofollow noreferrer"> 各种常见配置指南集</a> 可能会有所帮助。</p> <p>NB：有些请求很复杂，会发送一个 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests" rel="nofollow noreferrer">preflight</a> OPTIONS 请求，服务器必须先响应该请求，然后浏览器才会发送 JS 想要发出的 GET/POST/PUT/Whatever 请求。仅将 <code>Access-Control-Allow-Origin</code> 添加到特定 URL 的 CORS 实现通常会因此而出错。</p> <hr /> <p>显然，只有在满足以下任一条件时，Bob 才会通过 CORS 授予权限：</p> <ul> <li>数据不是私有的<em>或</em></li> <li>马洛里值得信赖</li> </ul> <hr /> <h2>如何添加这些标头？</h2> <p>这取决于你的服务器端环境。</p> <p>如果可以的话，使用专门用于处理 CORS 的库，因为它们将为您提供简单的选项，而不必手动处理所有内容。</p> <p><a href="https://enable-cors.org/server.html" rel="nofollow noreferrer">Enable-Cors.org</a> 有一个针对特定平台和框架的文档列表，您可能会觉得有用。</p> <h2>但我不是鲍勃！</h2> <p>Mallory<em> 没有标准机制来添加此标头，因为它必须来自 Bob 的网站，而她无法控制该网站。</em> </p>如果 Bob 正在运行公共 API，则可能有一种机制可以打开 CORS（可能通过以某种方式格式化请求，或者在登录到 Bob 站点的开发人员门户站点后的配置选项）。但这必须是 Bob 实现的机制。 Mallory 可以阅读 Bob 网站上的文档以查看是否有可用的内容，或者她可以与 Bob 交谈并要求他实施 CORS。<p> </p> <hr />提及“预检响应”的错误消息<h1> </h1>一些跨源请求是<p>预检的<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests" rel="nofollow noreferrer">.</a> </p>当（粗略地说）您尝试发出跨域请求时会发生这种情况：<p><ul> <li>包括cookie之类的凭证</li> <li>无法使用常规 HTML 表单生成（例如，设置无法在表单的 <code>enctype</code> 或某些其他请求标头中使用的 Content-Type）。</li> </ul> <h2>如果您正确执行了需要预检的操作</h2> <p>在这些情况下，<strong>这个答案的其余部分仍然适用</strong>，但您还需要确保服务器可以侦听预检请求（这将是<code>OPTIONS</code>（而不是<code>GET</code>、<code>POST</code> 或您尝试发送的任何内容）并使用正确的 <code>Access-Control-Allow-Origin</code> 标头以及 <code> 进行响应Access-Control-Allow-Methods</code> 和 <code>Access-Control-Allow-Headers</code> 允许您的特定 HTTP 方法或标头。</p> <h2>如果您错误地触发了预检</h2> <p>有时人们在尝试构建 Ajax 请求时会犯错误，有时这些错误会触发预检的需要。如果 API 设计为允许跨源请求，但不需要任何需要预检的内容，那么这可能会中断访问。</p> <p>触发此问题的常见错误包括：</p> <ul> <li>尝试将 <code>Access-Control-Allow-Origin</code> 和其他 CORS 响应标头放在请求上。这些不属于请求，不做任何有用的事情（您可以授予自己权限的权限系统有什么意义？），并且只能出现在响应中。</li> <li>尝试在没有请求正文来描述内容的 GET 请求上放置 <code>Content-Type: application/json</code> 标头（通常当作者混淆 <code>Content-Type## 时） # 和 </code>接受<code>).</code> </li> </ul>在这两种情况下，删除额外的请求标头通常足以避免预检的需要（这将解决与支持简单请求但不支持预检请求的 API 通信时的问题）。<p> </p> <hr />不透明响应（<h1>no-cors<code> 模式）</code> </h1>有时您需要发出 HTTP 请求，但不需要读取响应。例如如果您将日志消息发布到服务器进行记录。<p> </p>如果您使用<p>the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch" rel="nofollow noreferrer">fetch<code> API</code>（而不是</a>XMLHttpRequest<code>），那么您可以将其配置为不尝试使用CORS。</code> </p>请注意，<p>这不会让您执行任何需要 CORS 执行的操作<strong>。 </strong>您将无法阅读回复<strong>。您将无法提出需要预检的请求。</strong> </p>它会让您发出一个简单的请求，而不会看到响应，并且不会在开发者控制台中填充错误消息。<p> </p>当您使用 <p>fetch<code> 发出请求并且没有获得使用 CORS 查看响应的权限时，给出的 Chrome 错误消息解释了如何执行此操作：</code> ＃＃＃因此：＃＃＃雷雷 <hr /> <h1>CORS 的替代方案</h1> <h2>JSONP</h2> <p>Bob 还可以使用类似 <a href="https://stackoverflow.com/questions/2067472/what-is-jsonp-all-about">JSONP</a> 的 hack 来提供数据，这就是 CORS 出现之前人们进行跨域 Ajax 的方式。</p> <p>它的工作原理是以 JavaScript 程序的形式呈现数据，并将数据注入 Mallory 的页面。</p> <p>它要求 Mallory 信任 Bob 不会提供恶意代码。</p> <p>注意共同主题：提供数据的站点必须告诉浏览器第三方站点可以访问它发送到浏览器的数据。</p> <p>由于 JSONP 的工作原理是附加一个 <code><script></code> 元素，以 JavaScript 程序的形式加载数据，该程序调用页面中已有的函数，因此尝试在 URL 上使用 JSONP 技术返回 JSON 将失败 — 通常会出现 CORB 错误 — 因为 JSON 不是 JavaScript。</p> <h2>将两个资源移动到一个源</h2> <p>如果 JS 运行的 HTML 文档和请求的 URL 位于同一源（共享相同的方案、主机名和端口），则同源策略默认授予权限。不需要 CORS。</p> <h2>代理</h2> <p>Mallory <em>could</em> 使用服务器端代码来获取数据（然后她可以像往常一样通过 HTTP 将数据从服务器传递到 Alice 的浏览器）。</p> <p>它会：</p> <ul> <li>添加 CORS 标头</li> <li>将响应转换为 JSONP</li> <li>与 HTML 文档同源存在</li> </ul> <p>服务器端代码可以由第三方（例如 CORS Anywhere）编写和托管。请注意这对隐私的影响：第三方可以监控谁在其服务器上代理了什么。</p> <p>Bob 不需要授予任何权限即可发生这种情况。</p> <p>这里没有安全隐患，因为这只是 Mallory 和 Bob 之间的事情。 Bob 无法认为 Mallory 是 Alice，也无法向 Mallory 提供应在 Alice 和 Bob 之间保密的数据。</p> <p>因此，Mallory 只能使用此技术来读取 <em>public</em> 数据。</p> <p>但是请注意，从他人网站获取内容并自行展示可能会违反<em>版权</em>，并使您面临法律诉讼。</p> <h2>编写网络应用程序以外的东西</h2> <p>正如“为什么同源策略仅适用于网页中的 JavaScript”部分所述，您可以通过不在网页中编写 JavaScript 来避免 SOP。</p> <p>这并不意味着您不能继续使用 JavaScript 和 HTML，但您可以使用其他一些机制来分发它，例如 Node-WebKit 或 PhoneGap。</p> <h1>浏览器扩展</h1> <p>浏览器扩展可以在应用同源策略之前在响应中注入 CORS 标头。</p><p>这些对于开发很有用，但对于生产站点来说并不实用（要求站点的每个用户安装禁用其浏览器安全功能的浏览器扩展是不合理的）。</p> <p>它们也往往只适用于简单的请求（在处理预检选项请求时失败）。</p> <p>拥有适当的开发环境和本地开发<em>服务器</em> 通常是更好的方法。</p> <hr /> <h1>其他安全风险</h1> <p>请注意，SOP / CORS 不能缓解需要独立处理的 <a href="https://en.wikipedia.org/wiki/Cross-site_scripting" rel="nofollow noreferrer">XSS</a>、<a href="https://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="nofollow noreferrer">CSRF</a> 或 <a href="https://en.wikipedia.org/wiki/SQL_injection" rel="nofollow noreferrer">SQL 注入</a> 攻击。</p> <hr /> ＃＃＃概括＃＃＃ <h1> </h1>您无法在 <ul>your<li> 客户端代码中执行任何操作来启用 CORS 访问某人 <em>else 的 </em> 服务器。<em> </em>如果您控制服务器，则会发出请求：向其添加 CORS 权限。</li> <li>如果您与控制它的人很友好：让他们为其添加 CORS 权限。</li> <li>如果它是公共服务（请记住，</li>大多数第三方 API 都设计为仅通过服务器端代码进行交互，并且不支持 CORS<li>，但对于支持 CORS 的 API 除外）： <strong> </strong>阅读他们的 API 文档，看看他们是如何使用客户端 JavaScript 访问它的： <ul> <li>他们可能会告诉你使用特定的 URL<ul> <li>他们可能支持 JSONP 而不是 CORS</li> <li>他们可能根本不支持客户端代码的跨源访问（这可能是出于安全考虑而故意做出的决定，特别是如果您必须在每个请求中传递个性化的 API 密钥）。</li> <li> </li> </ul>确保您没有触发不需要的预检请求。 API 可能会授予简单请求的权限，但不会授予预检请求的权限。</li> <li> </li> </ul>如果以上都不适用：让浏览器与 </li>your<li> 服务器通信，然后让您的服务器从其他服务器获取数据并将其传递。（还有第三方托管服务将 CORS 标头附加到您可以使用的可公开访问的资源）。<em> </em>

XMLHttpRequest无法加载XXX，没有'Access-Control-Allow-Origin'头部

tl;dr; 关于同源策略

全部回复(2)我来回复

关于同源政策