目录

CORS跨域资源共享

简单跨域请求

非简单请求

CORS的安全问题

有关于浏览器的同源策略和如何跨域获取资源，传送门——> 浏览器同源策略和跨域的实现方法

同源策略（SOP）限制了应用程序之间的信息共享，并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时，也带来了另外的问题。随着Web应用程序和微服务使用的日益增长，出于实用目的往往需要将信息从一个子域传递到另一个子域，或者在不同域之间进行传递（例如将访问令牌和会话标识符，传递给另一个应用程序）。

为了允许跨域通信，开发人员必须使用不同的技术来绕过SOP并传递敏感信息，以至于现今也成为了一个棘手的安全问题。因此，为了在不影响应用程序安全状态的情况下实现信息共享，在HTML5中引入了跨源资源共享（CORS）。但问题也随之而来，许多人为了方便干脆直接使用默认的配置，或是由于缺乏对此的了解而导致了错误的配置。

CORS跨域资源共享

跨域资源共享(CORS)是一种放宽同源策略的机制，它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制，以使不同的网站可以跨域获取数据。

我们先来简单分析一下CORS跨域获取资源的过程：

CORS定义了两种跨域请求：简单请求 和 非简单请求。

简单跨域请求就是使用设定的请求方式请求数据
	
而非简单跨域请求则是在使用设定的请求方式请求数据之前，先发送一个OPTIONS预检请求，验证请求源是否为服务端允许源。只有"预检"通过后才会再发送一次请求用于数据传输。
当我们需要发送一个跨域请求的时候，浏览器会首先检查这个请求，如果它是简单跨域请求，浏览器就会立刻发送这个请求。如果它是非简单跨域请求，这时候浏览器不会马上发送这个请求，而是有一个跟服务器预检验证的过程。

简单跨域请求

（1) 请求方法是以下三种方法之一：
     HEAD
     GET
     POST
（2）HTTP的头信息不超出以下几种字段：
     Accept
     Accept-Language
     Content-Language
     Last-Event-ID
     Content-Type：application/x-www-form-urlencoded、 multipart/form-data、text/plain

只有同时满足以上两个条件时，才是简单请求，否则为非简单请求。

浏览器判断该请求为简单请求时，会在Request Header中添加 Origin 字段，它表示我们的请求源。

如下，简单请求头：



CORS服务端会将该字段作为跨源标志。CORS接收到此次请求后， 首先会判断Origin是否在允许源（由服务端决定）范围之内。

如果Origin指定的源在许可范围内，即验证通过，服务端会在Response Header 添加下面几个字段

Access-Control-Allow-Origin：该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。
	
Access-Control-Allow-Credentials：该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。当设置为true时，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可
	
Access-Control-Expose-Headers：该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。
如下，CROS服务端的回应：



如果Origin指定的源不在许可范围内，即验证失败，服务器也会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息中的Access-Control-Allow-Origin字段不包含访问源，就知道出错了，从而抛出同源检测异常的错误。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。





上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials:true

另一方面，开发者必须在AJAX请求中打开withCredentials属性 

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意浏览器发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，即Access-Control-Allow-Credentials:true时，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

总结：简单请求只需要CORS服务端在接受到携带Origin字段的跨域请求后，在response header中添加Access-Control-Allow-Origin等字段给浏览器做同源判断。

非简单请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。非简单请求的CORS请求，会在正式通信之前，增加一次OPTIONS方法的预检请求。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

下面简单分析一下非简单跨域请求的过程。浏览器先发送一个OPTIONS方法的预检请求。带有如下字段：

Origin: 在CORS中专门作为Origin信息供后端比对，表明来源域。
	
Access-Control-Request-Method:  接下来请求的方法，例如PUT、DELETE等等
	
Access-Control-Request-Headers: 自定义的头部，所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中
然后如果服务器配置了CORS，会返回对应对的字段，具体字段含义在返回结果是一并解释。

Access-Control-Allow-Origin:   允许进行跨域请求的域名
	
Access-Control-Allow-Methods:  允许进行跨域请求的方式
	
Access-Control-Allow-Headers:  允许进行跨区请求的头部
如下，OPTIONS预检的请求与相应



然后浏览器再根据服务器的返回值判断是否发送非简单请求。然后服务器处理完请求之后，会再返回结果中加上如下控制字段：

Access-Control-Allow-Origin: 允许跨域访问的域，可以是一个域的列表，也可以是通配符"*"。这里要注意Origin规则只对域名有效，并不会对子目录有效。即http://foo.example/subdir/ 是无效的。但是不同子域名需要分开设置，这里的规则可以参照同源策略
	
Access-Control-Allow-Credentials: 是否允许请求带有验证信息
	
Access-Control-Expose-Headers: 允许脚本访问的返回头，请求成功后，脚本可以在XMLHttpRequest中访问这些头的信息
	
Access-Control-Max-Age: 缓存此次请求的秒数。在这个时间范围内，所有同类型的请求都将不再发送预检请求而是直接使用此次返回的头作为判断依据，非常有用，大幅优化请求次数
	
Access-Control-Allow-Methods: 允许使用的请求方法，以逗号隔开
	
Access-Control-Allow-Headers: 允许自定义的头部，以逗号隔开，大小写不敏感
然后浏览器通过返回结果的这些控制字段来决定是将结果开放给客户端脚本读取还是屏蔽掉。如果服务器没有配置CORS，返回结果没有控制字段，浏览器会屏蔽脚本对返回信息的读取，并报出同源检测异常的错误！

通过上面叙述，我们得知借助CORS我们不必关心发出的请求是否跨域，浏览器会帮我们处理这些事情，但是服务端需要支持CORS，服务端实现CORS的原理也很简单，在服务端完全可以对请求做上下文处理，已达到接口允许跨域访问的目的。

当然，也有很多第三方的CORS插件，例如：Spring MVC 在4.2以上版本也支持了CORS配置，这样，服务端也无需自己操心了！

CORS的安全问题

CORS非常有用，可以共享许多内容，不过这里存在风险。因为它完全是一个盲目的协议，只是通过HTTP头来控制的。那么，CORS跨域资源共享漏洞是怎么发生的呢？由于程序员配置不当，Origin源不严格，从而造成跨域问题。

由以上可知，网站可以通过发送以下HTTP响应头部来启用CORS：

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

这样的话，就可以允许指定的源(http://example.com)来跨域请求服务器端的资源，并且服务器会响应。在默认情况下，发送跨域请求时不会携带cookie或其他凭据。因此，它不能用于窃取与用户相关的敏感信息（如CSRF令牌）。不过，网站服务器可以使用以下头部来启用凭据传输：

Access-Control-Allow-Credentials：true

这样浏览器在请求数据的时候就需要带上cookie。

实现对单个域的信任是非常容易的事情。不过，如果需要信任多个域的话，那该怎么办呢？根据相关规范的建议，只需列出相关的域，并用空格加以分隔即可，例如：

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

但是，没有哪个浏览器真正支持这一特性。

于是，我们可以通过使用通配符来信任所有子域，具体方法是：

Access-Control-Allow-Origin:  *.example.com

可是有一些偷懒的程序员，将Access-Control-Allow-Origin设置为允许来自所有域*的跨域请求。

Access-Control-Allow-Origin：*

这样，所有的网站都可以对其进行跨域资源请求了，这是非常危险的。不过先别高兴的太早。其实这里在设计的时候有一个很好的限制。xmlhttprequest发送的请求需要使用 "withCredentials" 来带上Cookie，如果一个目标域设置成了允许任意域的跨域请求，这个请求又带着 Cookie 的话，这个请求是不合法的。（就是如果需要实现带 Cookie 的跨域请求，CORS服务端需要明确的配置允许来源的域，使用任意域的配置是不合法的）浏览器会屏蔽掉返回的结果。Javascript 就没法获取返回的数据了。这是CORS模型最后一道防线。假如没有这个限制的话，那么 Javascript 就可以获取返回数据中的 Cookie 和 CSRF Token，以及各种敏感数据。这个限制极大的降低了CORS的风险。

如下，这是不允许的：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

这时，将在浏览器控制台中收到错误消息：当凭证标志为true时，无法在Access-Control-Allow-Origin中使用通配符(各个浏览器报错显示的不一样)。



那么，CORS的漏洞到底出现在哪里呢？

1：CORS服务端的 Access-Control-Allow-Origin 设置为了 *，并且 Access-Control-Allow-Credentials 设置为false，这样任何网站都可以获取该服务端的任何数据了。

2：有一些网站的Access-Control-Allow-Origin他的设置并不是固定的，而是根据用户跨域请求数据的Origin来定的。这时，不管Access-Control-Allow-Credentials 设置为了 true 还是 false。任何网站都可以发起请求，并读取对这些请求的响应。意思就是任何一个网站都可以发送跨域请求来获得CORS服务端上的数据。





下面的代码是通过AJAX来跨域请求获取服务端的数据

<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Ajax</title>
    <script type="text/javascript">
        function foo(){
            var xmlhttp=new XMLHttpRequest();
	    	var url="http://127.0.0.1/1.txt";   //要跨域访问的资源
            xmlhttp.open("POST",url,true);   
			//xmlhttp.setRequestHeader('X-PINGOTHER','AAAA');     //自定义头部，如果这样的话，就属于非简单请求了
			//xmlhttp.setRequestHeader('Content-Type','text/xml');   //自定义头部，如果这样的话，就属于非简单请求了
            xmlhttp.send();
            xmlhttp.onreadystatechange=function()
            {
                if (xmlhttp.readyState==4 && xmlhttp.status==200)
                {
                    document.getElementById("my").innerHTML=xmlhttp.responseText;
                }
            }
        }
    </script>
</head>
<body>
    <button id="btn" onclick="foo()">确定</button>
    <p id="my">hello,word!</p>
</body>
</html>

CORS漏洞的利用 

CORS（跨域资源共享）错误配置漏洞的高级利用

三种对CORS错误配置的利用方法

参考文章：对五家主流网站托管服务商进行的一次渗透测试

                  HTTP访问控制（CORS）

                  跨域——CORS详解

                  跨域资源共享 CORS 详解

                  如何利用CORS配置错误漏洞攻击比特币交易所

                

文章目录
跨源资源共享(CORS)
浏览器的同源策略
概念
特点
主要功能
跨域
主要跨域请求方法
JSONP跨域
CORS跨域
CORS的安全问题
三种不安全的配置引起的安全问题
通过CORS信任关系 利用XSS
使用错误的CORS破坏TLS
防御CORS
如何预防基于CORS的攻击
正确配置跨域请求
只允许信任的网站
避免将null列入白名单
避免在内部网络中使用通配符
CORS不能替代服务器端安全策略

跨源资源共享(CORS)
浏览器的同源策略
概念
根据字面意思就可以理解，同源策略是浏览器实施的一种关键机制，主要防止不同来源的干扰。所谓同源是指域名，协议，端口相同。
与其说同源策略的作用，不如说如果没有同源策略会产生什么后果，比如当你浏览网站A的同时也浏览了网站B，在该网站上运行的脚本代码将能访问你同时访问的网站B的数据和功能，此时如果网站A是恶意网站，如果网站B是网上银行，那么此时恶意站点就可以以你的名义进行转账。
特点

位于一个域的页面可以向另一个域提出请求
位于一个域的页面可以加载来自其他域的脚本并在自己的域中执行这个脚本（在授权的情况下）
位于一个域的页面无法读取或修改属于另一个域的cookie 或者其他DOM数据

主要功能
同源策略可以防止在一个域中运行的代码访问由其他域提供的内容
ps:但是很多功能是不受同源策略限制的：超链接、重定向、提交表单、嵌入到页面的图片等
跨域
主要跨域请求方法

JSONP
CORS

JSONP跨域
加载远程js,可以把远程js中数据带进来，一笔带过，这里并不是主要学习这个的。
CORS跨域
为了实现某些功能，允许浏览器向跨域服务器发出xmlhttprequest请求，克服SOP的限制实现跨域获取数据。
说明
最初XMLHttpRequest仅允许向与调用页面的来源相同的来源提出请求。随着HTML5的出现，这一技术得以修改，从而可以与其他域进行交互。
举例说明
首先看个实例说明一下，刚好我在逛b站，就随手抓了一个包----如图


请求头中的Origin字段

其中红色框框的origin字段表明该请求来源于https://message.bilibili.com

需要跨域请求时，浏览器会添加origin消息头，用于指示尝试提出跨域请求的域，对服务端来说，这个字段即是跨域标志。
当浏览器收到请求并收到这个字段，首先就会判断这个源是否在允许范围之内，如果是，也就出现了下面介绍的这些字段。

响应包中的4个响应字段



Access-Control-Allow-Origin字段在这里表示接受该域名的请求，有些情况会是 * 此时也就存在了安全风险。


Access-Control-Allow-Credentials：该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。当设置为true时，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。默认是false。


Access-Control-Expose-Headers：该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。


Access-Control-Allow-Methods: 允许使用的请求方法


CORS的安全问题
造成安全原因同样也是不安去的配置导致的，唉，不安全的配置会导致各种各样的漏洞，这也是这种缺陷一直位于owaspTop10的原因。
简单易懂的举个例子就是foo.com向bar.com发出请求时，如果响应头中包含了foo.com的CORS头，这样foo.com就可以携带cookie去调用bar.com了。
三种不安全的配置引起的安全问题

CORS服务端的 Access-Control-Allow-Origin 设置为了 * ,也就是说允许任何网站访问本服务器的资源。毫无疑问这是存在安全风险的

这里做一个实验，是一个在线实验室，就是针对这一类漏洞，如图

出现一个登入界面，使用提供给你的用户密码登入进去，点击我的账户，会发现会提供给你一个api key,并且这个服务器对跨域请求进行了不安全的配置，也就是上文提到的，这里只需要在请求头中添加Origin字段–如图

响应消息头中当然是不合法的，这个实验室同时也提供了可以利用的服务器，通过这个服务器获得本服务器的API
进入可利用服务器，向受害者服务器提出跨域请求，如图

完成攻击后，查看访问日志发现已经完成攻击。


还有一种漏洞是由于白名单的空原始值，请求消息头为Origin: null，某些应用程序可能会将null来源列入白名单，以支持应用程序的本地开发，这个实验内容和本实验类似。


返回报文头部Access-Control-Allow-Origin由请求报文Origin生成的（客户端可控数据），并且返回报文Access-Control-Allow-Credentials=true时，表明cookie可以包含在请求头中，一起发给服务器


配置了不严谨的正则表达式规则，也就是说对origin校验功能不完善，比如一种情况是只检查以a.com结尾的网站域名


origin:http://a.com

Access-Control-Allow-Origin:http://a.com
可以构造一个类似http://b.a.com 就能绕过其验证机制导致信息泄露，有些情况也会导致HTTP拆分注入攻击。
通过CORS信任关系 利用XSS
甚至“正确”配置的CORS也会在两个来源之间建立信任关系。如果网站信任易受跨站点脚本（XSS）攻击的来源，则攻击者可能利用XSS注入一些JavaScript，这些JavaScript使用CORS从信任易受攻击的应用程序的站点检索敏感信息。

开发人员用于对抗CORS利用的一种防御机制，是将频繁请求访问信息的域列入白名单。但这并不完全安全，因为只要白名单域中的一个子域易受到其他攻击（如XSS），那么也可以进行CORS利用。

https://www.cnblogs.com/linuxsec/articles/10584677.html 
这篇文章有几个实例和漏洞分析可以看看。
使用错误的CORS破坏TLS
假设严格使用HTTPS的应用程序还将使用纯HTTP的受信任子域列入白名单。例如，当应用程序收到以下请求时：
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...

该应用程序响应：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true

在这种情况下，能够拦截受害者用户流量的攻击者可以利用CORS配置破坏受害者与应用程序的交互。该攻击包括以下步骤：

受害用户发出任何普通的HTTP请求。
攻击者将重定向注入到： http://trusted-subdomain.vulnerable-website.com
受害者的浏览器遵循重定向。
攻击者拦截原始的HTTP请求，然后将包含CORS请求的欺骗响应返回给： https://vulnerable-website.com
受害者的浏览器发出CORS请求，包括来源： http://trusted-subdomain.vulnerable-website.com
该应用程序允许该请求，因为这是白名单来源。请求的敏感数据将在响应中返回。
攻击者的欺骗页面可以读取敏感数据，并将其传输到攻击者控制下的任何域。
即使易受攻击的网站对HTTPS的使用具有鲁棒性，没有HTTP终结点并且所有cookie被标记为安全，此攻击也有效。

防御CORS
如何预防基于CORS的攻击
CORS漏洞主要是由于配置错误而引起的。因此，预防是一个配置问题。以下各节介绍了一些针对CORS攻击的有效防御措施。
正确配置跨域请求
如果Web资源包含敏感信息，则应在Access-Control-Allow-Origin标头中正确指定来源。
只允许信任的网站
看起来似乎很明显，但是Access-Control-Allow-Origin标头中指定的来源只能是受信任的站点。特别是，无需验证就可以动态反映跨域请求的来源而无需验证，因此应避免使用。
避免将null列入白名单
避免使用标题Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定null来源。应针对私有和公共服务器的可信来源正确定义CORS标头。
避免在内部网络中使用通配符
避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅靠信任网络配置来保护内部资源是不够的。
CORS不能替代服务器端安全策略
CORS定义了浏览器的行为，绝不能替代服务器端对敏感数据的保护-攻击者可以直接从任何可信来源伪造请求。因此，除了正确配置的CORS之外，Web服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。
实验室和参考：
https://portswigger.net/web-security/cors

正在学习这个漏洞，有些错误的地方请指出，本人也会在以后的学习加以改正.

15 张精美动图全面讲解 CORS
前言
1.同源策略
为什么会存在同源策略
2.浏览器 CORS
3.服务端 CORS
响应头 Access-Control-Allow-Origin
Access-Control-Allow-Methods
4.预检请求
5.认证
6.总结

文章来源于微信公众号卤蛋实验室 ，作者卤代烃


前言
本文翻译自 Lydia Hallie[1]小姐姐写的 ✋🏼🔥 CS Visualized: CORS[2]，她用了大量的动图去解释 CORS 这个概念，国内还没有人翻译本文，所以我在原文的理解上翻译了本文并修改了一些错误，希望能帮到大家。
觉得翻译的不错一定要点赞哦，谢谢你，这对我真的很重要！🌟

注：文的动图均为 keynote 制作

CORS 的全名是Cross-Origin Resource Sharing，即跨域资源共享
前端开发过程中，我们经常要使用其他站点的数据。前端显示这些数据之前，必须向服务器发出请求以获取该数据。
假设我们正在访问https://api.mywebsite.com这个站点，点击按钮向  https://api.mywebsite.com/users发送请求，获取网站上的一些用户信息：



PS:

这里原作者有个笔误，左边手机截图把https://api.mywebsite.com误写为https://www.mywebsite.com了，图中也有这个错误，读者要注意一下不要被误导
从结果上看表现非常完美，我们向服务器发送请求，服务器返回了我们需要的 JSON 数据，前端也正常的渲染出了结果。
下面我们换一个网站试试。用  https://www.anotherwebsite.com 这个网站向 https://api.website.com/users 发送请求：


问题来了，我们请求同样的接口网站，但是这次浏览器给我们抛出一个 Error。
刚刚浏览器抛出的就是 CORS Error，下面让我们分析一下为什么会产生这种 Error，以及这个 Error 的确切含义是什么。
1.同源策略
浏览器网络请求时，有一个同源策略的机制。即默认情况下，使用 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源。
比如说， https://www.mywebsite.com 请求  https://www.mywebsite.com/page 是完全没有问题的。

但是当资源位于协议、域名和端口有任何一个不同的站点时，这个请求就是跨域的。

前端应该知道的AJAX



目前来看，同源策略会让三种行为受限：

Cookie、LocalStorage 和 IndexDB 访问受限
无法操作跨域 DOM（常见于 iframe）
Javascript 发起的 XHR 和 Fetch 请求受限

IndexDB入门-阮一峰
为什么会存在同源策略
那么，为什么会存在同源策略呢？
我们做个假设，如果不存在同源策略，你无意中点击了七大姑在微信上给你发的一篇养生文章链接。其实这个网页是个钓鱼网站，访问链接后就把你重定向到一个嵌入了 iframe 的攻击网站，这个iframe会自动加载银行网站，并通过 cookies 登录你的账户。
登陆成功后，这个钓鱼网站还可以控制 iframe 的 DOM，通过一系列骚操作把你卡里的钱转走。



这是一个非常严重的安全漏洞，我们不希望自己在互联网的内容被随便访问，更不要说这种涉及到钱的网站了。
同源策略可以帮助我们解决这个安全问题，这个策略确保我们只能访问同一站点的资源。


在这种情况下，https://www.evilwebsite.com尝试跨站访问 https://www.bank.com 的资源，同源策略就会阻止这个操作，让钓鱼网站无法访问银行网站的数据。
说了这么多，同源策略和 CORS 又有什么关系？
2.浏览器 CORS
出于安全原因，浏览器限制从脚本内发起的跨域 HTTP 请求。

例如 XHR 和Fetch 就遵循同源策略。这意味着使用 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源。



日常的业务开发中，我们会经常访问跨域资源，为了安全的请求跨域资源，浏览器使用一种称为 CORS 的机制。
CORS 的全名是 Cross-Origin Resource Sharing，即跨域资源共享。尽管默认情况下浏览器禁止我们访问跨域资源，但是我们可以利用CORS 放宽这种限制，在保证安全性的前提下访问跨域资源。
浏览器可以利用CORS 机制，放行符合规范的跨域访问，阻止不合规范的跨域访问。浏览器内部是怎么做的呢？我们下面就来分析一下。
Web程序发出跨域请求后，浏览器会自动向我们的 HTTP header 添加一个额外的请求头字段：Origin。Origin 标记了请求的站点来源：
GET https://api.website.com/users HTTP/1/1
Origin: https://www.mywebsite.com // <- 浏览器自己加的



为了使浏览器允许访问跨域资源， 服务器返回的 response 还需要加一些响应头字段，这些字段将显式表明此服务器是否允许这个跨域请求。
3.服务端 CORS
作为服务器开发人员，我们可以通过在 HTTP 响应中添加额外的响应头字段 Access-Control-*来表明是否允许跨域请求。根据这些 CORS 响应头字段，浏览器可以允许一些被同源策略限制的跨源响应。
虽然有好几个 CORS 响应头字段[3]，但有一个字段是必加的，那就是Access-Control-Allow-Origin。这个头字段的值指定了哪些站点被允许跨域访问资源。
响应头 Access-Control-Allow-Origin
1️⃣ 如果我们有服务器的开发权限，我们可以给 https://www.mywebsite.com 加上访问权限：将该域添加到 Access-Control-Allow-Origin 中。



这个响应头字段现在被添加到服务器发回给客户端的 response header 中。这个字段添加后，如果我们从https://www.mywebsite.com 发送跨域请求，同源策略将不再限制 https://api.mywebsite.com 站点返回的资源。
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.mywebsite.com
Date: Fri, 11 Oct 2019 15:47 GM
Content-Length: 29
Content-Type: application/json
Server: Apache

{user: [{...}]}


2️⃣ 收到服务器返回的 response 后，浏览器中的 CORS 机制会检查 Access-Control-Allow-Origin的值是否等于 request 中 Origin的值。
在这个例子中，request 的 Origin 是https://www.mywebsite.com，这和response 中 Access-Control-Allow-Origin的值是一样的：


3️⃣ 浏览器校验通过，前端成功地接收到跨域资源。
那么，当我们试图从一个没有在Access-Control-Allow-Origin中列出的网站跨域访问这些资源会发生什么呢？



如上图所示，从 https://www.anotherwebsite.com 跨域访问 https://api.mywebsite.com 资源，浏览器抛出一个 CORS Error，经过上面的讲解，我们可以读懂这个报错信息了：
The 'Access-Control-Allow-Origin' header has a value
 'https://www.mywebsite.com' that is not equal 
to the supplied origin. 

在这种情况下，Origin 的值是 https://www.anotherwebsite.com。然而，服务器在 Access-Control-Allow-Origin 响应头字段中没有标记这个站点，浏览器 CORS 机制就阻止了这个响应，我们无法在我们的代码中获取响应数据。

CORS 还允许我们添加通配符 *作为允许的外域，这意味着该资源可以被任意外域访问，所以要注意这种特殊情况

Access-Control-Allow-Origin 是 CORS 机制提供的众多头字段之一。服务器开发人员还可以通过其它头字段扩展服务器的 CORS 策略，以允许/禁止某些请求。
Access-Control-Allow-Methods
另一个常见的响应头字段是 Access-Control-Allow-Methods。其指明了跨域请求所允许使用的 HTTP 方法。


在上图的案例中，只有GET，POST 或PUT 方法被允许跨域访问资源。其他 HTTP 方法，例如 PATCH 和 DELETE 都会被阻止。

如果您想知道其它的 CORS 响应头字段是什么以及它们的用途，可以查看此列表[4]。

说到PUT，PATCH和 DELETE 这几个 HTTP 方法，CORS 处理这些方法时还有些不同。这些非简单请求会触发 CORS 的预检请求。
4.预检请求
CORS 有两种类型的请求：一种是简单请求（simple request），一种是预检请求（preflight request）。

一个跨域请求到底是简单的的还是预检的，取决于一些request header。
当请求是 GET 或 POST 方法并且没有任何自定义 Header 字段时，一般来说就是个简单请求。除此之外的任何请求，诸如PUT，PATCH或 DELETE 方法，将会产生预检请求。

如果你想知道一个请求必须满足哪些要求才能成为简单请求，可以查看 MDN 简单请求相关的文档[5]。

说了这么多，预检请求到底是什么意思？下面我们就来探讨一下。
1️⃣ 在发送实际请求之前，客户端会先使用 OPTIONS[6] 方法发起一个预检请求，预检请求的 Access-Control-Request-*中包含有关我们将要处理的实际请求的信息：
首部字段 Access-Control-Request-Method[7] 告知服务器，实际请求要用到的方法是什么

首部字段 Access-Control-Request-Headers[8] 告知服务器，实际请求将附带的自定义请求首部字段是什么
OPTIONS https://api.mywebsite.com/user/1 HTTP/1.1
Origin: https://www.mywebsite.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type



2️⃣ 服务器接收到预检请求后，会返回一个没有 body 的 HTTP 响应，这个响应标记了服务器允许的HTTP 方法和 HTTP Header字段：
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.mywebsite.com
Access-Control-Request-Method: GET POST PUT
Access-Control-Request-Headers: Content-Type

3️⃣ 浏览器收到预检响应，并检查是否应允许发送实际请求。



⚠️：上图预检响应漏了 Access-Control-Allow-Headers: Content-Type

4️⃣ 如果预检响应检测通过，浏览器会将实际请求发送到服务器，然后服务器返回我们需要的资源。



如果预检响应没有检验通过，CORS 会阻止跨域访问，实际的请求永远不会被发送。预检请求是一种很好的方式，可以防止我们访问或修改那些没有启用 CORS 策略的服务器上的资源。

💡 为了减少网络往返次数，我们可以通过在CORS请求中添加 Access-Control-Max-Age

头字段来缓存预检响应。浏览器可以使用缓存来代替发送新的预检请求

5.认证
XHR 或Fetch 与 CORS 的一个有趣的特性是，我们可以基于 Cookies[9]和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XHR 或 Fetch 请求，浏览器不会发送身份凭证信息。
尽管 CORS 默认情况下不发送身份凭证，但我们可以通过添加 Access-Control-Allow-Credentials CORS 响应头来更改它。
如果要在跨域请求中包含cookie 和其他授权信息，我们需要做以下操作：

XHR 请求中将 withCredentials 字段设置为true
Fetch 请求中将 credentials 设为include
服务器把 Access-Control-Allow-Credentials: true 添加到响应头中

// 浏览器 fetch 请求
fetch('https://api.mywebsite,com.users', {
  credentials: "include"
})

// 浏览器 XHR 请求
let xhr = new XMLHttpRequest();
xhr.withCredentials = true;

// 服务器添加认证字段
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true



把上面的工作做好后，我们就可以在跨域请求中包含身份凭证信息了。
6.总结
CORS Error 一定程度上会让前端开发很头疼，但是遵循它的相关规定后，它可以让我们在浏览器中进行安全的跨域请求。
同源策略和 CORS 的知识点有很多，本文只讲了一些关键知识点，如果你想全面学习 CORS 的相关知识，我推荐你查阅MDN 文档[10]和 W3C 规范[11]，这些一手知识是最准确的。

谢谢你阅读到了最后~

期待你关注、收藏、评论、点赞~

参考资料

[1]

Lydia Hallie: https://dev.to/lydiahallie
[2]

✋🏼🔥 CS Visualized: CORS: https://dev.to/lydiahallie/cs-visualized-cors-5b8h?utm_campaign=React%2BNative%2BNow&utm_medium=web&utm_source=React_Native_Now_69#cs-cors
[3]

好几个 CORS 响应头字段: https://fetch.spec.whatwg.org/#http-responses
[4]

查看此列表: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#The_HTTP_response_headers
[5]

文档: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests
[6]

OPTIONS: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/OPTIONS
[7]

Access-Control-Request-Method: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Request-Method
[8]

Access-Control-Request-Headers: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Request-Headers
[9]

Cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
[10]

MDN 文档: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS
[11]

W3C 规范: https://www.w3.org/wiki/CORS_Enabled
[12]

X-Forwarded-For 拿到的就是真实 IP 吗？: https://juejin.im/post/6844904174132396045
[13]

HTTP 请求中，空格应该被编码为 %20 还是 + ？: https://juejin.im/post/6844904178267979783

跨域资源共享CORS学习笔记



1、同源政策



含义

1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。

最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页”同源”。所谓”同源”指的是”三个相同”。



协议相同
域名相同
端口相同

举例来说，http://www.example.com/dir/page.html这个网址，协议是http://，域名是www.example.com，端口是80（默认端口可以省略）。它的同源情况如下。



http://www.example.com/dir2/other.html：同源
http://example.com/dir/other.html：不同源（域名不同）
http://v2.www.example.com/dir/other.html：不同源（域名不同）
http://www.example.com:81/dir/other.html：不同源（端口不同）



目的

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？

很显然，如果 Cookie 包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是，Cookie 往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。

由此可见，”同源政策”是必需的，否则 Cookie 可以共享，互联网就毫无安全可言了。



限制范围

随着互联网的发展，”同源政策”越来越严格。目前，如果非同源，共有三种行为受到限制。



（1） Cookie、LocalStorage 和 IndexDB 无法读取。
（2） DOM 无法获得。
（3） AJAX 请求不能发送。

对于跨域问题，可以简单理解为：浏览器执行javascript脚本时，会检查这个脚本属于哪个页面，如果不是同源页面，就不会被执行。

对于它通常有三种解决办法：

JSONP：JSONP只支持GET请求
代理：例如www.123.com/index.html需要调用www.456.com/server.php，可以写一个接口www.123.com/server.cgi，由这个接口在后端去调用www.456.com/server.php并拿到返回值，然后再返回给index.html，这就是一个代理的模式。相当于绕过了浏览器端，自然就不存在跨域问题。
SERVER端支持CORS，即增加对Origin等字段判断，返回响应是增加Access-Control-Allow-Origin、Access-Control-Allow-Method等字段
代理方法比较清晰，是直接通过先访问同源后端接口，通过后端接口去访问跨域资源，也就不会存在跨域的问题（跨域的问题仅存在于，浏览器执行javascript脚本时）

但代理模式也有比较明显的缺点，比如如果浏览器访问的页面需要访问的域名的资源是不断变化，那么使用代理模式就要频繁改动代码，扩展性很差，所以并不是一个好的选择。

JSONP:jsonp（json width padding）是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。由于同源策略，一般来说位于service.example.com的网页无法与不是service2.example.com的服务器沟通，而HTML的script元素是一个列外。利用script圆度开放策略，网页可以等到从其他源动态产生的JSON资料，而这种使用模式就是所谓的JSONP。用JSONP抓到的资料并不是JSON，而是任意的Javascript，用javascript直译器执行而不是用JSON解析器解析。

但JSONP有几个问题，一是要求客户必须限制使用JSONP，这个方案并不是后端SERVER支持跨域；二则是JSONP只支持GET方法。

JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

这里总结下上面的内容：如果用户使用不支持跨域的APIGW作为中间件连接后端server，那么是无法通过浏览器访问后端server的，基本就代表着使用qcloud APIGW完成的代码，无法使用浏览器。。包括桌面浏览器、移动浏览器以及APP内置使用的webview均无法使用

CORS与JSONP的使用目的相同，但是比JSONP更强大。这里着重介绍下CORS跨域资源共享



2、跨域资源共享



定义

跨来源资源共享（Cross-Origin Resource Sharing（CORS））是一种使用额外HTTP标头来让目前浏览网站的user agent能获得访问不同来源（网域）服务器特定资源之权限的机制。当user agent请求一个不是目前文件来源——来自于不同网域（domain）、通信协定（protocol）或通信端口（port）的资源时，会建立一个跨来源HTTP请求（cross-origin HTTP request）。

基于安全性考虑，浏览器和WebView发出的HTTP请求会有限制。例如，XMLHttpRequest及Fetch皆遵守同源政策（same-origin policy）。这代表网络应用程序所使用的这些API只能请求来自和应用程序相同网域的HTTP资源，除非使用了CORS标头。



哪些请求会使用到CORS?

使用XMLHttpRequest或Fetch API进行跨站请求，如前所述。
网页字体（跨网域CSS的@font-face的字体用途），所以服务器可以部属TrueType字体并限制仅让被许可的网站进行跨站加载使用。 

WebGL纹理。
以drawImage绘制到Canvas画布上的图形／视频之影格。
CSS样式表（让CSSOM存取）。
指令码（for unmuted exceptions）
跨域请求详解

CORS需要浏览器和服务器同时支持。当前桌面和移动浏览器对CORS的支持情况如下：



a、浏览器端支持情况

桌面浏览器：

浏览器
  
Chrome
  
Edge
  
FireFox
  
IE
  
Opera
  
Safari
支持CORS最低版本
  
4
  
12
  
3.5
  
10
  
12
  
4
- IE8 和 IE9 通过 XDomainRequest 插件支持CORS，IE10 开始则完全正常支持CORS。 

- Firefox 3.5 支持跨域 XMLHttpRequests 与 Web Fonts，较旧版本上某些请求会有限制。 Firefox 7 支持 WebGL 纹理的跨域 HTTP 请求，而 Firefox 9 新增支持使用 drawImage 方法，将图形绘制于 canvas 中。

移动浏览器：

浏览器
  
Android webview
  
Chrome for Android
  
Edge mobile
  
Firefox for Android
  
IE mobile
  
Opera Android
  
iOS Safari
支持CORS最低版本
  
2.1
  
ALL
  
ALL
  
4
  
ALL
  
12
  
3.2
整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源通信没有差别，代码完全一样。浏览器一旦发现HTTP请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求（复杂请求），但用户不会感知。

支持CORS的主要改动点在server端



b、两种跨域请求

浏览器将CORS请求分成两类：简单请求（simple request）和预检请求。

同时满足以下条件，那么就是简单请求。



（1) 请求方法是以下三种方法之一：
HEAD
GET
POST
（2）HTTP的头信息不超出以下几种字段：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
（3）没有事件监听器被注册到任何用来发出请求的 XMLHttpRequestUpload 上（经由 XMLHttpRequest.upload 方法取得）上。
（4）请求中没有 ReadableStream 类型的内容被用于上传。


  
PS：虽然这些都是网页目前已经可以送出的跨站请求，除非后端服务器回复正确CORS标志，否则不会有内容传回来，因此不允许跨域请求的网站无须担心会受到新的HTTP 存取控制的影响。


通常情况下主要涉及条件（1）和条件（2）

如果不满足上述条件任何一个，那么它就是预检请求。



c、简单请求

浏览器发现自己发送的是简单跨域请求，则会只发送一次HTTP请求。相较于同源请求，CORS简单请求会在头信息中额外增加一个Origin字段。

下图是一个简单跨域请求例子：浏览器发现本次请求是跨域请求，就会自动在请求头信息中增加Origin字段（依赖于浏览器机制/或者JS解释器的实现） 



请求和响应内容如下：

假定是从apigw.qcloud.com去请求qcloud.com的资源



请求
GET /resources/public-data/ HTTP/1.1
Host: qcloud.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://apigw.qcloud.com


响应
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

HTTP请求中的Origin字段表示该请求是来自于http://apigw.qcloud.com的请求

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: application/xml

本次请求示例中响应是携带了Access-Control-Allow-Origin: *，或者是Access-Control-Allow-Origin: http://apigw.qcloud.com

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段，就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。



d、预检请求

不满足简单请求条件之一的即是非简单请求。非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为”预检”请求（preflight）。

「预检（preflighted）」请求会先用HTTP 的OPTIONS 方法请求另一个域名资源，确认后续实际（actual）请求能否可安全送出。由于跨域请求可能会携带使用者的信息，所以要先进行预检请求。

下图是一个预检请求例子：



请求和响应内容如下：

假定是从apigw.qcloud.com去请求qcloud.com的资源

第一次是预检请求／响应：



OPTIONS /resources/post-here/ HTTP/1.1
Host: qcloud.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://apigw.qcloud.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://apigw.qcloud.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

等到预检请求完成后，浏览器才会发送真正的响应：



POST /resources/post-here/ HTTP/1.1
Host: qcloud.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Content-Length: 55
Origin: http://apigw.qcloud.com
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://apigw.qcloud.com
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

先看请求，Access-Control-Request-Method告诉服务器发的请求是POST请求，Access-Control-Request-Headers通知自己带有X-PINGOTHER自定义header

再看响应，Access-Control-Allow-Origin这个与前面类似，Access-Control-Allow-Methods这里说明支持POST/GET/OPTIONS方法，Access-Control-Allow-Headers这里说明允许X-PINGOTHER自定义header，Access-Control-Max-Age用来指定本次预检请求的有效时间，86400是24小时也就是一天。


  
问题：1、若简单跨域请求校验失败，APIGW应如何回复？ 

  2、若预检跨域请求校验失败，APIGW应如何回复？ 

  3、目前浏览器并不支持预检请求的重定向，如果发生了预检请求的重定向，则浏览器会大概率报错


一旦服务器通过了”预检”请求，在Access-Control-Max-Age指定的时间内，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。



e、HTTP跨域请求标识

Origin

Origin 字段表示了跨域请求的来源或者预检请求的来源。在任何跨域请求中，一定要携带Origin字段



Origin: <origin>

Access-Control-Request-Method（仅在预检请求中）

Access-Control-Request-Method 是用在预检请求中，告诉后端server实际请求用的HTTP方法



Access-Control-Request-Method: <method>

Access-Control-Request-Headers（仅在预检请求中）

Access-Control-Request-Headers标识用于预检请求中，它会告诉后端server自己所携带的自定义header字段有哪些



Access-Control-Request-Headers: <field-name>[, <field-name>]*



f、HTTP跨域响应标识

Access-Control-Allow-Origin

跨域响应会携带该字段，若服务器允许所有uri来访问自己的资源，那么则该字段为*；若要允许http://www.qq.com访问该资源，则为Access-Control-Allow-Origin: http://www.qq.com



Access-Control-Allow-Origin: <origin> | *

Access-Control-Expose-Headers

Access-Control-Expose-Headers表示服务器允许浏览器从响应中解析哪些header字段



Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

表示服务器允许浏览器从响应中解析X-My-Custom-Header, X-Another-Custom-Header字段

Access-Control-Max-Age

Access-Control-Max-Age表示预检请求结果请求成功后，多长时间内非简单请求可以不需要再发预检请求，可以继续直接使用跨域请求请求资源



Access-Control-Max-Age: <delta-seconds>

Access-Control-Allow-Credentials

这里下次补充。



Access-Control-Allow-Credentials: true

Access-Control-Allow-Methods（仅在预检请求响应中）

Access-Control-Allow-Methods表示服务器访问操作该资源允许哪些方法



Access-Control-Allow-Methods: <method>[, <method>]*

Access-Control-Allow-Headers(仅在预检请求响应)

Access-Control-Allow-Headers表示在访问这个域资源的时候，预检请求响应中哪些header字段可以在跨域请求中使用

Access-Control-Allow-Headers: <field-name>[, <field-name>]*



2、后端server实现CORS功能可以参考如下代码

KONG CORS模块：https://github.com/Kong/kong/tree/master/kong/plugins/cors

GO http middlerware：https://github.com/rs/cors

3、参考文档

http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

http://www.ruanyifeng.com/blog/2016/04/cors.html

https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS#Preflighted_requests