关于前端:腾讯一面CORS为什么能保障安全为什么只对复杂请求做预检

7次阅读

共计 2237 个字符，预计需要花费 6 分钟才能阅读完成。

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

但如果问你：

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

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

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

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

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

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

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

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

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

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

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

申请办法是 HEAD/GET/POST

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

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

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

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

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

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

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

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

它的根本流程如下：

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

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

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

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

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

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

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

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

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

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

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

点个关注更好！

正文完