大家好，我是年年！
提起 CORS，大部分的文章都在写什么是简略申请、什么是简单申请，简单申请预检的流程又是怎么。

但如果问你：

1. CORS 为什么要带上源，这是为了保障以后站点的平安还是目标服务器的平安？
2. 为什么辨别简略申请和简单申请，只对简单申请做预检？

这篇文章会围绕 CORS 是如何保障平安的的，讲清这几个问题。读完能够对 CORS 知其然，并知其所以然。

什么是 CORS

置信每个前端的控制台都中都被打印过这样一段话，通知你：你的跨域申请策略拦挡啦！

首先要明确的一点，CORS 的目标不是拦挡申请，反倒是为了让其能失常申请。

CORS 诞生的背景是「同源策略」。这是一个相当严苛的规定，它禁止了跨域的 AJAX 申请。但理论的开发中又有这样的需要，于是开一个口子——只有配置了 CORS 的对应规定，跨域申请就能失常进行。这也正和 CORS 的名字对应起来了——「跨域资源共享」，就是为了能让跨域申请在「同源策略」的大背景下进行。

回到下面提到控制台报错，这不是阻止你做跨域申请，而是提醒你：因为没有依照 CORS 要求做配置，不得不临时拦挡。

怎么配置 CORS

上文讲清了，只有依照 CORS 要求做配置，就能冲破同源策略的限度，上面将会讲述如何配置。

这部分不须要前端操心，齐全后端来做：在响应头外面加一个字段Access-Control-Allow-Origin（容许申请的起源），这个值要把前端的源蕴含进去。

举个例子：申请的后端接口是 http://fe_nian，你本地正在开发前端工程跑在 8080 端口。那么后端会在响应头里加上Access-Control-Allow-Origin:* 来容许 http://localhost:8080 这个源去做跨域申请，因为 * 是所有的意思。

跨域申请的流程

CORS 把申请分成简略申请和简单申请，划分的根据是“是否会产生副作用”。

简略贴一下定义，同时满足上面这两个条件的是简略申请

1. 申请办法是 HEAD/GET/POST
2. 申请体的文件类型只能是 form-urlencoded、form-data、text/plain（这类文章很多，不再赘述，能够看阮一峰 - 跨域资源共享）

对于简略申请，流程如下：

1. 浏览器发动申请，并且主动加上申请的起源 origin 给服务器查看；
2. 服务器返回数据，并返回查看后果，配置 CORS 响应头；
3. 浏览器查看 CORS 响应头，如果蕴含了以后的源则放行，反之拦挡；

这里须要留神，浏览器是拦挡响应，而不是拦挡申请，跨域申请是收回去的，并且服务端做了响应，只是浏览器拦挡了下来。

对于简单申请，整个流程如下：

1. 浏览器发动预检申请，带上申请的起源origin，不蕴含申请体；
2. 服务器返回查看后果，配置 CORS 头；
3. 浏览器发动真正申请；
4. 浏览器返回数据；

浏览器会查看第 2 步中拿到的 CORS 头，如果没有蕴含以后的源，后续的第 3、4 步都不会进行，也就是不会发动真正申请。

为什么要带上源

CORS 给开发带来了便当，同时也带来了安全隐患——CSRF 攻打。

它的根本流程如下：

1. 用户登录受益网站，把获取的身份凭证保留在浏览器的 cookie 中。也就是上图流程的①②③；
2. 用户用同一浏览器关上黑客网站，黑客网站向受益网站服务器发动一个歹意申请，这时浏览器会主动从 cookie 中取出身份凭证，把它带上。也就是上图的④⑤；
3. 受益网站服务端发现有身份凭证，歹意申请被胜利受理；

如果严格依照同源政策，第 2 步的跨域申请不能进行的，也就不会造成危害。所以 CORS 策略的心智模型是：所有跨域申请都是不平安的，浏览器要带上起源给服务器测验。

如果做过服务端开发，应该晓得，服务端不存在跨域一说，去获取另一个服务器的资源是再顺畅不过的事件。因为服务端不像浏览器一样，作为“容器”存贮着用户身份凭证——也就是下面的第 1 步产生的事件，它去做跨域申请没有这样的危险。

为什么只对简单申请做预检

上文提到，划分简略申请和简单申请的根据是“是否产生副作用”。这里的副作用指对数据库做出批改：应用 GET 申请获取新闻列表，数据库中的记录不会做出扭转，而应用 PUT 申请去批改一条记录，数据库中的记录就产生了扭转。

对于简略申请，浏览器只会在申请头加上一个 origin 字段标识申请起源；对于非简略申请，浏览器会先收回一个预检申请，取得必定答复后才会发送真正的申请，上面会讲清楚为什么这么做。

能够假如网站被 CSRF 攻打了——黑客网站向银行的服务器发动跨域申请，并且这个银行的安全意识很弱，只有有登录凭证 cookie 就能够胜利响应：

1. 黑客网站发动一个 GET 申请，目标是查看受益用户本月的账单。银行的服务器会返回正确的数据，不过影响并不大，而且因为浏览器的拦挡，最初黑客也没有拿到这份数据；
2. 黑客网站发动一个 PUT 申请，目标是把受益用户的账户余额清零。浏览器会首先做一次预检，发现收到的响应并没有带上 CORS 响应头，于是真正的 PUT 申请不会收回；

幸好有预检机制，否则 PUT 申请一旦收回，黑客的攻打就胜利了。

结语

回到结尾的两个问题，不难得出答案：

1. 对于跨域申请带上申请起源，是为了避免 CSRF 攻打；浏览器的心智模型是：跨域申请都是不平安的，CORS 的机制是为了保障申请目标服务器的平安；
2. 根据是否对服务器有副作用，划分了简略申请和简单申请（但因为历史起因，表单 POST 申请也被划分成了简略申请），预检机制会把不平安的简单申请拦挡下来，防止对服务器造成危害，而简略申请通常不会对服务器的资源作出批改，即便收回危害不大。

如果这篇文章对你有帮忙，给我点个赞呗，这是我创作的能源～

点个关注更好！