在 CORS 请求的 POST 之前使用 OPTION 请求背后的原因是什么? [英] What is the reason behind using OPTION request before POST on CORS requests?

问题描述

在实际POST、UPDATE、PUT或之前发送OPTION请求背后的原因是什么?code>DELETE 请求何时调用不同的域?(所以在 CORS 请求上)我知道它应该检查服务器是否可以处理真正的请求，但为什么不立即发送真正的请求呢?

What is the reason behind sending an OPTION request before the actual POST, UPDATE, PUT or DELETE request when a different domain is called? (So on CORS requests) I know it supposed to check whether the server can process the real request but why not send just the real request immediately?

我考虑过的一些原因:

1. 查看是否支持该方法
   • 发送真正的请求会返回相同的状态码，所以无需先发送 OPTION 请求.

• 没有任何意义，因为 OPTION 请求没有发送任何身份验证标头

• Make no sense as no auth headers are sent with the OPTION requests

• 毫无意义，因为在处理数据之前检查身份验证规则.

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

• 这是唯一有效的原因.使用选项请求将防止不必要地将发布数据发送到服务器.但是我认为这在 99% 的情况下都不是问题，因为只发送了一小块数据.

有人可以解释浏览器供应商在调用不同域时实施 OPTION 请求的原因吗?

Can someone shed some light on the reasons why browser vendors implemented OPTION requests when calling a different domain?

推荐答案

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

CORS is a basically a browser security feature not server side.

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

By default the browser will NOT allow certain cross origin requests. The server you're talking to can publish whether or not it's safe to use cross origin requests but it's the client that understands and uses that information and therefore provides the protection not the server.

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

So for a GET request you can get the resource, check the CORS header and then decide whether to process it or not based on the header. Nice and simple.

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

For a POST (or other changing) event it's not so simple. You make the POST request, the server process it (remember the server doesn't care about CORS, only the browser) and sends back the response. The browser sees CORS is not enabled and ignores the response but by that point it's too late - the POST request has been processed at the server side and all that's prevented is the display of the results that it's been processed. So for an online banking application, for example, a malicious request to transfer funds means the funds will be transferred but your browser will ignore the "funds transferred successfully" response - big deal the damage is done as the money is gone and the malicious request would likely have ignored the response anyway!

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

So you can't send the request until you know what the CORS header will be on the response - which requires sending the request! Chicken and egg situation.

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

So the browser sends an OPTIONS request to the same address which doesn't change anything like a POST request might, but does return the CORS header. After that the browser knows whether it's safe to send the real request.

顺便说一句，服务器不实现 CORS 安全性的原因是更改 Referrer 标头非常容易，因此无论如何它都不会提供任何保护.服务器将具有其他安全功能(例如检查会话是否有效并授权发出请求)，但是 CORS 旨在防止的攻击是一种没有帮助的攻击(例如用户已登录到他们在另一个标签上的网上银行).

And btw the reason that a server doesn't implement CORS security is that it's incredibly easy to alter the Referrer header so it wouldn't offer any protection anyway. The server will have other security features (e.g. checking session is valid and authorised to make the request) but an attack that CORS is designed to prevent is one where these don't help (e.g. user is logged in to their online banking on another tab).

这篇关于在 CORS 请求的 POST 之前使用 OPTION 请求背后的原因是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！