Access-Control-Allow-Origin 标头如何工作？

Access-Control-Allow-Origin 是一个 CORS (Cross-Origin Resource Sharing) header。

当站点 A 尝试从站点 B 获取内容时，站点 B 可以发送一个 Access-Control-Allow-Origin 响应标头，告诉浏览器该页面的内容可以访问某些来源。 （origin 是 domain, plus a scheme and port number。）默认情况下，站点 B 的页面是 not accessible to any other origin；使用 Access-Control-Allow-Origin 标头为特定请求来源的跨域访问打开了大门。

对于站点 B 希望站点 A 可以访问的每个资源/页面，站点 B 应为其页面提供响应标头：

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

现代浏览器不会直接阻止跨域请求。如果站点 A 从站点 B 请求页面，浏览器实际上将获取请求的页面在网络级别，并检查响应标头是否将站点 A 列为允许的请求者域。如果站点 B 未表示允许站点 A 访问此页面，则浏览器将触发 XMLHttpRequest 的 error 事件并拒绝对请求 JavaScript 代码的响应数据。

非简单请求

网络级别发生的事情可能稍微比上面解释的要复杂。如果请求是 "non-simple" request，浏览器首先发送一个无数据的“预检”OPTIONS 请求，以验证服务器是否会接受该请求。当任一（或两者）时，请求是非简单的：

使用 GET 或 POST 以外的 HTTP 动词（例如 PUT、DELETE）

使用非简单的请求头；唯一简单的请求标头是：Accept Accept-Language Content-Language Content-Type（仅当其值为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 时才简单）

接受

接受语言

内容-语言

Content-Type（只有当它的值为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 时才很简单）

如果服务器使用与非简单动词和/或非简单标头匹配的适当响应标头（Access-Control-Allow-Headers 用于非简单标头，Access-Control-Allow-Methods 用于非简单动词）响应 OPTIONS 预检，则浏览器发送实际请求。

假设站点 A 想要发送一个对 /somePage 的 PUT 请求，且 Content-Type 的非简单值为 application/json，浏览器将首先发送一个预检请求：

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

请注意，Access-Control-Request-Method 和 Access-Control-Request-Headers 是由浏览器自动添加的；您不需要添加它们。此 OPTIONS 预检获取成功的响应标头：

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

发送实际请求时（预检完成后），其行为与处理简单请求的方式相同。换句话说，预检成功的非简单请求被视为与简单请求相同（即，服务器仍必须再次发送 Access-Control-Allow-Origin 以获得实际响应）。

浏览器发送实际请求：

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

并且服务器发回一个 Access-Control-Allow-Origin，就像它对一个简单的请求一样：

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

有关非简单请求的更多信息，请参阅 Understanding XMLHttpRequest over CORS。

---

跨域资源共享 - CORS（AKA 跨域 AJAX 请求）是大多数 Web 开发人员可能会遇到的问题，根据 Same-Origin-Policy，浏览器将客户端 JavaScript 限制在安全沙箱中，通常 JS 无法直接与来自不同域的远程服务器。过去开发人员创造了许多棘手的方法来实现跨域资源请求，最常用的方法有：

使用 Flash/Silverlight 或服务器端作为“代理”与远程通信。带填充的 JSON (JSONP)。将远程服务器嵌入 iframe 并通过片段或 window.name 进行通信，请参阅此处。

这些棘手的方法或多或少都有一些问题，例如如果开发人员简单地“评估”它，JSONP 可能会导致安全漏洞，以及上面的#3，虽然它有效，但两个域应该在彼此之间建立严格的契约，它既不灵活也不优雅恕我直言：）

W3C 引入了跨域资源共享 (CORS) 作为标准解决方案，以提供安全、灵活和推荐的标准方法来解决此问题。

机制

从高层次上，我们可以简单地认为 CORS 是来自域 A 的客户端 AJAX 调用与域 B 上托管的页面之间的合约，典型的跨域请求/响应将是：

DomainA AJAX 请求标头

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

DomainB 响应标头

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

我在上面标记的蓝色部分是核心事实，“Origin”请求标头“指示跨域请求或预检请求的来源”，“Access-Control-Allow-Origin”响应标头指示此页面允许远程请求来自DomainA（如果值为 * 表示允许来自任何域的远程请求）。

正如我上面提到的，W3 建议浏览器在提交实际的跨域 HTTP 请求之前实现“preflight request”，简而言之，它是一个 HTTP OPTIONS 请求：

OPTIONS DomainB.com/foo.aspx HTTP/1.1

如果 foo.aspx 支持 OPTIONS HTTP 动词，它可能会返回如下响应：

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

只有响应包含“Access-Control-Allow-Origin”且值为“*”或包含提交CORS请求的域时，满足此强制条件，浏览器才会提交实际的跨域请求，并缓存结果在“预检结果缓存”中。

三年前我写过关于 CORS 的博客：AJAX Cross-Origin HTTP request

---

问题有点太老了，无法回答，但我发布这个以供将来参考这个问题。

根据 this Mozilla 开发者网络文章，

当资源从与第一个资源本身服务的域或端口不同的域或端口请求资源时，它会发出跨域 HTTP 请求。

https://i.stack.imgur.com/zn3sT.png

从 http://domain-a.com 提供的 HTML 页面 向 http://domain-b.com/image.jpg 发出 <img> src 请求。
当今网络上的许多页面加载资源，例如 CSS 样式表，<来自不同域的strong>图像和脚本（因此应该很酷）。

同源政策

出于安全原因，浏览器会限制跨域 HTTP 请求从脚本中发起。
例如，XMLHttpRequest 和 Fetch 遵循 相同的 -源策略。
因此，使用 XMLHttpRequest 或 Fetch 的网络应用程序只能向 其自己的域发出 HTTP 请求。

跨域资源共享 (CORS)

为了改进 Web 应用程序，开发人员要求浏览器供应商允许跨域请求。

跨域资源共享 (CORS) 机制为 Web 服务器提供跨域访问控制，从而实现安全的跨域数据传输。
现代浏览器使用 CORS 在 API 容器（例如 XMLHttpRequest 或 Fetch）中，以降低跨域 HTTP 请求的风险。

CORS 的工作原理（Access-Control-Allow-Origin 标头）

Wikipedia：

CORS 标准描述了新的 HTTP 标头，它为浏览器和服务器提供了一种仅在获得许可时才请求远程 URL 的方法。尽管服务器可以执行一些验证和授权，但通常浏览器有责任支持这些标头并遵守它们施加的限制。

例子

浏览器发送带有 Origin HTTP 标头的 OPTIONS 请求。此标头的值是为父页面提供服务的域。当来自 http://www.example.com 的页面尝试访问 service.example.com 中的用户数据时，将向 service.example.com 发送以下请求标头： 来源：http://www.example。 com service.example.com 上的服务器可能会响应： 响应中的 Access-Control-Allow-Origin (ACAO) 标头，指示允许哪些源站点。例如： Access-Control-Allow-Origin: http://www.example.com 如果服务器不允许跨域请求，则会出现错误页面 带有通配符的 Access-Control-Allow-Origin (ACAO) 标头允许所有域：访问控制允许来源：*

---

每当我开始考虑 CORS 时，我对哪个站点托管标头的直觉是不正确的，正如您在问题中所描述的那样。对我来说，考虑同源政策的目的是有帮助的。

同源策略的目的是保护您免受 siteA.com 上的恶意 JavaScript 访问您选择仅与 siteB.com 共享的私人信息。如果没有同源策略，siteA.com 的作者编写的 JavaScript 可能会使用您对 siteB.com 的身份验证 cookie 使您的浏览器向 siteB.com 发出请求。这样，siteA.com 就可以窃取您与 siteB.com 共享的秘密信息。

有时您需要跨域工作，这就是 CORS 的用武之地。CORS 放宽了 siteB.com 的同源策略，使用 Access-Control-Allow-Origin 标头列出受信任以运行可以交互的 JavaScript 的其他域 (siteA.com)与siteB.com。

要了解哪个域应该为 CORS 标头提供服务，请考虑这一点。您访问了恶意网站，其中包含一些试图向 mybank.com 发出跨域请求的 JavaScript。应该由 mybank.com 而非恶意网站来决定它是否设置 CORS 标头以放宽相同的来源策略，从而允许来自恶意网站的 JavaScript 与之交互。如果 malicous.com 可以设置自己的 CORS 标头，允许其自己的 JavaScript 访问 mybank.com，这将完全取消同源策略。

我认为我直觉不好的原因是我在开发网站时的观点。这是我的站点，包含我所有的 JavaScript，因此它没有做任何恶意行为，应该由我来指定我的 JavaScript 可以与哪些其他站点交互。事实上，我应该考虑哪些其他网站 JavaScript 正在尝试与我的网站交互，我应该使用 CORS 来允许它们吗？

---

根据我自己的经验，很难找到一个简单的解释，为什么 CORS 甚至是一个问题。

一旦你理解了它为什么存在，标题和讨论就会变得更加清晰。我会在几行中试一试。

这都是关于饼干的。 Cookies 按其域存储在客户端上。

一个例子：在您的计算机上，有一个 yourbank.com 的 cookie。也许你的会话在那里。

关键点：当客户端向服务器发出请求时，它将为该请求发送存储在域下的 cookie。

您已在浏览器上登录 yourbank.com。您请求查看您的所有帐户，并为 yourbank.com 发送 cookie。 yourbank.com 收到一堆 cookie 并发回其响应（您的帐户）。

如果另一个客户端向服务器发出跨源请求，这些 cookie 会像以前一样被发送。鲁罗。

您浏览到恶意网站。恶意软件向不同的银行发出大量请求，包括 yourbank.com。

由于 cookie 按预期进行验证，服务器将授权响应。

这些 cookie 被收集起来并一起发送 - 现在，malware.com 收到了 yourbank 的回复。

哎呀。

所以现在，一些问题和答案变得显而易见：

“我们为什么不直接阻止浏览器这样做呢？”是的。 CORS。

“我们如何绕过它？”让服务器告诉请求 CORS 正常。

---

1。客户端从 http://siteA - 源下载 javascript 代码 MyCode.js。

进行下载的代码 - 您的 html 脚本标签或来自 javascript 的 xhr 或其他 - 来自 http://siteZ。而且，当浏览器请求 MyCode.js 时，它会发送一个 Origin: 标头说“Origin: http://siteZ”，因为它可以看到您正在向 siteA 和 siteZ 请求！= siteA。 （您不能停止或干预。）

2。 MyCode.js 的响应头包含 Access-Control-Allow-Origin: http://siteB，我认为这意味着 MyCode.js 被允许对站点 B 进行跨域引用。

不。这意味着，仅允许 siteB 执行此请求。因此，您从 siteZ 对 MyCode.js 的请求反而会收到错误，而浏览器通常不会给您任何信息。但是如果你让你的服务器返回 ACAO: siteZ ，你会得到 MyCode.js 。或者如果它发送'*'，那会起作用，这会让每个人都进入。或者如果服务器总是从 Origin: 标头发送字符串......但是......为了安全，如果你害怕黑客，您的服务器应该只允许入围名单上的来源，允许发出这些请求。

然后，MyCode.js 来自 siteA。当它向siteB发出请求时，它们都是跨域的，浏览器发送Origin：siteA，并且siteB必须获取siteA，识别它在允许的请求者的短名单上，然后发回ACAO：siteA。只有这样，浏览器才会让您的脚本获得这些请求的结果。

---

使用 React 和 Axios，将代理链接加入 URL 并添加标题，如下所示

https://cors-anywhere.herokuapp.com/ + Your API URL

只需添加代理链接即可，但它也可能再次引发 No Access 错误。因此最好添加标题，如下所示。

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

警告：不得用于生产

这只是一个快速修复，如果您在为无法获得响应而苦苦挣扎，您可以使用它。但这又不是生产的最佳答案。得到了几次反对票，这完全有道理，我早就应该添加警告。

---

如果您只想测试浏览器阻止您的请求的跨域应用程序，那么您可以在不安全模式下打开浏览器并测试您的应用程序，而无需更改代码，也不会使您的代码不安全。在 MAC OS 中，您可以从终端行执行此操作：

open -a Google\ Chrome --args --disable-web-security --user-data-dir

---

如果您使用的是 PHP，请尝试在 php 文件的开头添加以下代码：

如果您使用的是本地主机，请尝试以下操作：

header("Access-Control-Allow-Origin: *");

如果您使用的是外部域，例如服务器，请尝试以下操作：

header("Access-Control-Allow-Origin: http://www.website.com");

---

我使用 express 4 和 node 7.4 和 angular，我遇到了同样的问题，我可以帮助解决这个问题：a）服务器端：在 app.js 文件中，我为所有响应提供标题，例如：

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

这必须在所有路由器之前。我看到很多添加了这个标题：

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

但我不需要那个，b）客户端：在发送ajax中你需要添加：“withCredentials：true”，比如：

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

---

在 Python 中，我使用 Flask-CORS library 取得了巨大成功。它使处理 CORS 变得超级简单和轻松。我从下面的库文档中添加了一些代码。

安装：

$ pip install -U flask-cors

允许对所有路由上的所有域进行 CORS 的简单示例：

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

有关更具体的示例，请参阅文档。我已经使用上面的简单示例来解决我正在构建的必须访问单独的烧瓶服务器的离子应用程序中的 CORS 问题。

---

对于跨域共享，设置标题：'Access-Control-Allow-Origin':'*';

php：header('Access-Control-Allow-Origin':'*');

节点：app.use('Access-Control-Allow-Origin':'*');

这将允许共享不同域的内容。

---

只需将以下代码粘贴到您的 web.config 文件中。

请注意，您必须在 <system.webServer> 标记下粘贴以下代码

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

---

我无法在后端服务器中配置它，但浏览器中的这些扩展对我有用：

对于 Firefox： Cors Everywhere

对于谷歌浏览器： Allow CORS: Access-Control-Allow-Origin

注意：CORS 使用此配置为我工作：

https://i.stack.imgur.com/eDD7P.jpg

https://i.stack.imgur.com/27QWb.jpg

---

Nginx 和阿帕奇

作为 apsillers answer 的补充，我想添加 wiki graph，它显示请求何时简单（以及 OPTIONS 飞行前请求是否发送）

https://i.stack.imgur.com/BTFel.png

对于简单的请求（例如 hotlinking images），您不需要更改服务器配置文件，但您可以在应用程序（托管在服务器上，例如在 php 中）中添加标头，如 Melvin Guerrero 在他的 answer 中提到的 - 但 remember ：如果您在服务器（配置）中添加完整的 cors 标头，同时您允许在应用程序（例如 php）上使用简单的 cors，这根本不起作用。

这是两个流行服务器的配置

打开 Nginx 上的 CORS（nginx.conf 文件）位置 ~ ^/index\.php(/|$) { ... add_header 'Access-Control-Allow-Origin' "$http_origin" always; # 如果您将“$http_origin”更改为“*”，您应该得到相同的结果 - 允许所有域使用 CORS（但最好将其更改为您的特定域） add_header 'Access-Control-Allow-Credentials' 'true' always; if ($request_method = OPTIONS) { add_header 'Access-Control-Allow-Origin' "$http_origin"; # 不要删除此行（与上面的外部“if”加倍） add_header 'Access-Control-Allow-Credentials' 'true'; add_header '访问控制-最大年龄' 1728000; # 缓存 20 天的预检值 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; # 任意方法 add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # 任意标题 add_header 'Content-Length' 0; add_header 'Content-Type' 'text/plain charset=UTF-8';返回204； } }

在 Appache (.htaccess 文件) 上打开 CORS # ---------------------------------------- --------------------------------------- # |跨域 Ajax 请求 | #------------------------------------------------ ----------------------------- # 启用跨域 Ajax 请求。 # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity # http://enable-cors.org/ # 将下面的 *（允许任何域）更改为您的域标题集 Access-Control-Allow-Origin "*" 标头始终设置 Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" 标头始终设置 Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content -type, csrf-token" 标头始终设置 Access-Control-Allow-Credentials "true"

---

Access-Control-Allow-Origin 响应标头指示响应是否可以与来自给定源的请求代码共享。

Header type Response       header
Forbidden header name      no

告诉浏览器允许来自任何来源的代码访问资源的响应将包括以下内容：

Access-Control-Allow-Origin: *

有关详细信息，请访问 here....

---

仅用于测试的临时解决方案：

谁无法控制 Options 405 Method Not Allowed 的后端。
Chrome 浏览器的解决方法。
在命令行中执行：
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="path_to_profile"
示例：
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\Users\vital\AppData\Local\Google\Chrome\User Data\Profile 2"

---

对于带有 Angular 的 .NET Core 3.1 API

Startup.cs : 添加 CORS

    //SERVICES
    public void ConfigureServices(IServiceCollection services){

        //CORS (Cross Origin Resource Sharing)
        //=====================================
        services.AddCors();
    }

    //MIDDLEWARES
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();

        //ORDER: CORS -> Authentication -> Authorization)
        //CORS (Cross Origin Resource Sharing)
        //=====================================  
        app.UseCors(x=>x.AllowAnyHeader().AllowAnyMethod().WithOrigins("http://localhost:4200"));

        app.UseHttpsRedirection();
    }
}

控制器：为授权控制器启用 CORS

 //Authorize all methods inside this controller
 [Authorize]
 [EnableCors()]
 public class UsersController : ControllerBase
 {
    //ActionMethods
 }

---