在发布CORS请求之前使用OPTION request的原因是什么？[副本]

Question

在调用不同域时，在实际的POST、UPDATE、PUT或DELETE请求之前发送选项请求的原因是什么？（所以对于CORS请求）我知道它应该检查服务器是否能够处理真正的请求，但是为什么不立即发送真正的请求呢？

我考虑过的一些原因：

• 查看是否支持该方法

• 没有任何意义，因为没有授权头与OPTION请求一起发送

• 没有意义，因为检查身份验证规则是在处理数据之前。

• 这就是它现在的工作方式，但是为什么不发送请求呢？我们可以从真实的请求中读取错误

• 这是唯一有效的理由。使用options request将防止不必要地向服务器发送post数据。然而，我认为这在99%的时间里都不是问题，因为只发送了一小部分数据

有人能解释一下为什么浏览器供应商在调用其他域时执行选项请求吗？




Answer 1

CORS基本上是一种浏览器安全功能，而不是服务器端。

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

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

对于POST（或其他变化）事件来说，这并不是那么简单。您发出POST请求，服务器处理它（记住服务器不关心CORS，只关心浏览器）并发送回响应。浏览器看到CORS未启用并忽略响应，但此时已经太迟了-POST请求已在服务器端处理，阻止的只是显示已处理的结果。因此，对于网上银行应用程序，例如，恶意转账请求意味着资金将被转账，但您的浏览器将忽略“资金转账成功”响应-这是一件大事，因为钱已经用完了，所以造成了损失，而且恶意请求很可能会忽略响应！

因此，在知道响应上的CORS标头之前，您无法发送请求-这需要发送请求！鸡和蛋的情况。

因此，浏览器向同一地址发送一个选项请求，该地址不会像POST请求那样发生任何更改，但会返回CORS头。之后，浏览器知道发送真实请求是否安全。

顺便说一句，服务器不实现CORS安全性的原因是，修改referer头非常容易，因此它不会提供任何保护。服务器将具有其他安全功能（例如，检查会话是否有效并有权发出请求），但CORS旨在防止的攻击是这些功能没有帮助的攻击（例如，用户在另一个选项卡上登录到他们的网上银行）。