一文搞懂跨域 CORS
前言
我们做服务端开发的时候，可能都遇到过前端同学说请求我们的接口被 cors 拦截了，出现 has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested 类似的报错，
这就是遇到了跨域问题。
跨域问题是如何产生的
首先需要明确一点，出现上文的报错是浏览器拦截导致的，即使服务端没有做任何拦截动作，这个报错都会出现。
<table><tbody><tr><td><p>如果把这个报错的请求复制到postman或者用curl去请求，可以发现其是可以正常响应的。</p></td></tr></tbody></table>
那么浏览器什么时候会拦截呢，答案是请求的 origin 和 host 不同的时候，且 host 服务器没有显示声明允许 origin 请求访问，那么浏览器就会拦截。
CSRF（Cross-site request forgery）
CSRF，又称为跨站请求伪造：即攻击者在第三方网站上，向目标网站（被攻击对象）发送跨站请求，利用浏览器上已经保存的目标网站的 cookie 等数据，从而以受害者的身份在目标网站上执行某项操作。
举个例子
假设有这样一个通讯录网站 knox 通讯录，这个网站登录后会把 cookie 存到本地，后续网站会用 cookie 来验证用户身份。
一天，小明在登录这个网站备份好自己的通讯录信息后，就去刷贴吧了，结果看到这样一条帖子
<table><tbody><tr><td><p>最新漏洞，速看免费刷Q币的方法</p></td></tr></tbody></table>
小明不禁好奇点击了进去，结果发现链接网页上写了一大堆没用的话，小明吐槽了一句骗子就关掉了网页，然而不久小明的朋友们都收到了冒着小明名义的各种各样的诈骗短信，
原来当小明点击诈骗链接的时候，这个网页就向通讯录网站发送了查看通讯录信息的请求，因为通讯录的信息在浏览器上有保存，发起请求的时候浏览器就把 cookie 带上了。 而通讯录网站收到请求后验证没有问题，就返回了通讯录信息，从而骗子拿到小明朋友的电话等信息。
以上就是一个典型的 CSRF 攻击的例子，攻击者构造第三方网站诱骗用户点击，在第三方网站对目标网站发起请求，来执行某些攻击操作。
为什么要限制跨域
在了解完 CSRF 后，我们可以发现这个攻击是发生在第三方网站，对目标网站的攻击。
因此浏览器对于这种请求做了限制，当目标网站和源网站域名不一致的时候，浏览器默认会拦截这次请求。只有目标网站在返回中显示声明了 Access-Control-Allow-Origin: ${第三方网站域名}，浏览器才可以正常将请求返回。
<table><tbody><tr><td><p>注意，浏览器限制跨域 限制的是跨域请求的返回，如果目标网站没有做任何同域检测，CSRF攻击仍然有可能成功。</p></td></tr></tbody></table>
跨域问题怎么解
这里讨论的是如何避免浏览器出现诸如 has been blocked by CORS policy 这样的非预期报错。
前面说了浏览器出现 cors 拦截是因为目标网站没有显示声明允许第三方网站访问，那么加上这个声明即可。
目标网站在相应的 header 中加上
Access-Control-Allow-Origin: ${第三方网站域名}
比如 foo.example 访问 bar.example，那么 bar.example 的 responset header 中需要加上 Access-Control-Allow-Origin: foo.example
以上是最简单的，CORS 相关的特性还有很多，分别针对不同的场景，下面我们详细看下
简单请求和预检请求
浏览器在发起跨域请求的时候，会根据请求参数的将请求分为简单请求和预检请求
简单请求：浏览器直接发起访问
预检请求：浏览器先发起一个 OPTIONS 请求，只有这个请求被允许后，才会发送原来真正的请求。
简单请求
简单请求定义
请求方法为以下之一： GET、HEAD、POST
允许请求设置的 header 只能有以下几种：Accept、Accept-Language、Content-Language、Contentt-Type、Range，除这些 header 外，还可以包含被用户代理自动设置的标头字段（例如 Connection、User-Agent 或其他在 Fetch 规范中定义为禁用标头名称的标头，比如 Cookie）
如果设置了 Content-Type，他的值只能是以下几种：text/plain、multipart/form-data、application/x-www-form-urlencoded
如果请求是 xmlhttpRequest，没有监听 upload 的 event，即没有调用 xhr.upload.addEventListner
请求没有使用 ReadableStream
一个简单请求的交互如下
预检请求
和简单请求不同，预检请求不是直接发送原先的请求，而是发送一个 OPTIONS 请求到服务器，以或者服务器是否允许该实际请求。
什么请求需要预检：除了简单请求罗列的情况外，都需要进行预检。
预检的流程：
请求如下，第一次的 OPTIONS 请求只会包含请求 header，不会包含实际的 body。交互流程如下图
预检请求的缓存
预检请求的结果浏览器是可以缓存到本地的，这样不用每次发送请求前都预检一次。
这个缓存的控制通过 Access-Control-Max-Age 控制，这个头指定了预检请求的结果能够缓存多久，单位是秒。
下次请求如果在有效期内，就不会再次预检。
Vary
上面说到预检请求的结果会缓存到本地，默认情况下 缓存的 key 是 host + method。
这种情况下是假设无论哪个网站访问目标网站预检请求结果都是一致的。
但是如果服务器希望允许跨域的网站有多个，那么服务器返回的 header 中需要加上 vary:origin，用于告诉浏览器缓存 key 需要加上 origin。
为什么需要预检请求
CROS 规范里并没有解释为什么需要预检，但是我们可以想到的是
因为 CROS 拦截是后置的，有了预检请求，可以防止一些请求对服务端数据造成影响。
减少网络带宽消耗，如果一个请求会被拒绝，那么其 body 的传递就是没有必要的。
跨域 Cookie 策略
浏览器发起的跨域请求，默认是不带 Cookie 的。如果希望发送 Cookie 信息，需要在请求的时候显示设置,如下所示
<table><tbody><tr><td><p>JavaScript
var xhr = new XMLHttpRequest();
xhr.open('GET','https://www.baidu.com',true);
// 显示制定带上Cookie
xhr.withCredentials=true;
xhr.onreadystatechange = function(){ console.log(xhr.getAllResponseHeaders()); }
xhr.send(null);</p></td></tr></tbody></table>
通过这样的设置，浏览器发送跨域请求的时候会带上 Cookie 发送到目标机器。但是注意，如果服务器的响应 header 中没有包含 Access-Control-Allow-Credentials:true，浏览器也是不会将响应返回给请求的发送者。
简单请求：简单请求可以直接用 withCredentials=true 来携带 Cookie
预检请求：预检请求不可以携带 Cookie，并且如果正式请求希望携带 Cookie，预检请求的返回必须携带 Access-Control-Allow-Credentials:true
响应限制
如果请求附带有身份凭证（Cookie），响应 header 中对通配符做了如下限制
服务器不能将 Access-Control-Allow-Origin 设置为*，而必须是特定的域
服务器不能将 Access-Control-Allow-Methods 设置为*，而必须是具体的 method 列表
服务器不能将 Access-Control-Allow-Headers 设置为*，而必须是具体的 header 列表
如果不满足上述条件，浏览器发起的跨域请求会失败。
模拟跨域
环境搭建
<table><tbody><tr><td><p>Plain Text
git clone https://github.com/knoxgao67/VinciToolkit.git
cd VinciTookit
git checkout feat/cors
cd cors
# start http ui server
go run webA/main.go -p 8000
# start http web server
go run webB/main.go -p 8001
</p></td></tr></tbody></table>
打开浏览器 访问 localhost:8000,可以看到这个界面
webA 是模拟的第三方网站
webB 是跨域目标网站
Case1: 简单请求-允许
选择 path /simple_request/allowed,点击按钮 1
<table><tbody><tr><td><p><img src="https://upload-images.jianshu.io/upload_images/5899140-5b4d4e1926e68122.png"></p></td><td><p><img src="https://upload-images.jianshu.io/upload_images/5899140-8dfc59657e393e73.png"></p></td></tr></tbody></table>
可以看到 webB response header 中有 Access-Control-Allow-Origin:*，请求被允许
Case2 : 简单请求-拒绝
选择 path /simple_request/rejected，点击按钮 1
<table><tbody><tr><td><p><img src="https://upload-images.jianshu.io/upload_images/5899140-b1210be75e1e4d68.png"></p></td><td><p><img src="https://upload-images.jianshu.io/upload_images/5899140-d043d146b46729b5.png"></p></td></tr></tbody></table>
可以看到返回中没有 Access-Control-Allow-Origin，这个请求就被拒绝了。
且在浏览器 console 中我们可以看到如下报错
Case3: 预检请求-允许
预检请求查看
选择 path /comp_request/allowed，点击按钮 2
这个复杂请求，会在 header 带上一个非标字段 a=1,这种情况下会触发预检请求
点击完按钮 2 之后，效果如下
可以看到请求发送了 2 次，第一次是 preflight，只有第一次通过后才进行第二次真正请求
preflight 请求参数如下
<table><tbody><tr><td><p>request声明了非标字段</p><p>Response header中需要显示声明允许的header</p></td><td><p><img src="https://upload-images.jianshu.io/upload_images/5899140-a541a34a7f1cf3b9.png"></p></td></tr></tbody></table>
预检请求缓存
默认预检请求是有缓存的，短时间内第二次访问是不会触发预检请求的，
可以通过连续几次点击按钮 2 进行模拟，效果如图
Case4: 预检请求-拒绝
选择 path/comp_request/reject_for_headers，点击按钮 2。
这个 path 的响应没有将 Access-Control-Allow-Headers 返回，所以浏览器进行了报错
Case5: 预检请求-Cookie
点击按钮 3，这个请求会要求模拟携带 Cookie 进行访问的情况
允许：选择 path /comp_request/allowed_with_cookie
携带 Cookie 的时候，服务器响应的时候需要显示的指定允许携带 Cookie
拒绝：选择 path /comp_request/allowed
服务器响应该 path 的时候并没有将 Access-Control-Allow-Credentials:true 返回，所以浏览器会进行拦截
TODO
预检请求，vary 还没有得到预期验证，在学习中
本文由mdnice多平台发布
