在POST之前在CORS请求上使用OPTION请求的原因是什么？

Question

在调用其他域时,在实际POST,UPDATE,PUT或DELETE请求之前发送OPTION请求的原因是什么？(所以关于CORS请求)我知道它应该检查服务器是否可以处理真实请求,但为什么不立即发送真实请求？

我想到的一些原因:

1. 查看该方法是否受支持
2. 发送实际请求将返回相同的状态代码,因此无需先发送OPTION请求.
3. 检查用户是否允许发送请求
   • 没有意义,因为没有与OPTION请求一起发送auth标头
4. 防止服务器上的负载过重
   • 没有意义,因为在处理数据之前检查auth规则.
5. 检查是否允许请求的标题和来源
   • 这就是它现在的工作原理,但为什么不发送请求,我们可以从真实请求中读取错误.
6. 如果不处理,阻止发送帖子数据
   • 这是有效的唯一原因.使用选项请求将阻止不必要地将发布数据发送到服务器.但是我认为这在99%的时间里都不是问题,因为只发送了一小部分数据.

有人可以了解浏览器供应商在调用其他域时实施OPTION请求的原因吗？

Answer 1

CORS基本上是一个浏览器安全功能,而不是服务器端.

默认情况下,浏览器不允许某些跨源请求.您正在与之交谈的服务器可以发布使用跨源请求是否安全,但是客户端是理解并使用该信息的,因此提供的保护不是服务器.

因此,对于GET请求,您可以获取资源,检查CORS标头,然后根据标头决定是否处理它.很好,很简单.

对于POST(或其他更改)事件,它不是那么简单.你发出POST请求,服务器处理它(记住服务器不关心CORS,只关心浏览器)并发回响应.浏览器看到CORS未启用并忽略响应,但到那时为时已晚 - POST请求已在服务器端处理,所有阻止的是显示已处理的结果.因此,对于网上银行应用程序,例如,转移资金的恶意请求意味着资金将被转移,但您的浏览器将忽略"成功转移资金"的响应 - 因为资金消失和恶意请求造成损失很大反正可能会忽略回应!

因此,在知道响应中的CORS标头之前,您无法发送请求 - 这需要发送请求!鸡肉和鸡蛋的情况.

因此,浏览器向相同的地址发送OPTIONS请求,该地址不会像POST请求那样改变任何内容,但会返回CORS头.之后,浏览器知道发送真实请求是否安全.

而且服务器没有实现CORS安全性的原因是,改变Referrer头部非常容易,因此无论如何它都不会提供任何保护.该服务器将具有其他安全功能(如检查会话是有效的,并授权给发出请求),但CORS是为了防止攻击的一个地方,这些并不能帮助(例如,用户在登录到网上银行的另一个选项卡上).