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

Question

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

我想到的一些原因：

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

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

Answer 1

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

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

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

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

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

因此，浏览器会向同一地址发送OPTIONS请求，不可能会更改POST请求，但会返回CORS标头。之后浏览器知道发送真实请求是否安全。

并且说服务器没有实现CORS安全性的原因是，改变Referrer头部非常容易，因此无论如何它都不会提供任何保护。服务器将具有其他安全功能（例如，检查会话是有效的并且有权发出请求）但CORS旨在防止的攻击是这些无法帮助的攻击（例如用户 登录在另一个标签上的网上银行）。