Html CORS - 引入预检请求的动机是什么？

CORS - What is the motivation behind introducing preflight requests?

提问by jan groth

Cross-origin resource sharingis a mechanism that allows a web page to make XMLHttpRequests to another domain (from wikipedia).

跨域资源共享是一种允许网页向另一个域（来自wikipedia）发出 XMLHttpRequests 的机制。

I've been fiddling with CORS for the last couple of days and I think I have a pretty good understanding of how everything works.

在过去的几天里，我一直在摆弄 CORS，我想我对一切都是如何工作的有了很好的了解。

So my question is not about how CORS / preflight work, it's about the reason behind coming up with preflights as a new request type. I fail to see any reason why server A needs to send a preflight (PR) to server B just to find out if the real request (RR) will be accepted or not - it would certainly be possible for B to accept/reject RR without any prior PR.

所以我的问题不是关于 CORS/预检如何工作，而是关于将预检作为新请求类型的原因。我看不出为什么服务器 A 需要向服务器 B 发送预检（PR）只是为了确定真正的请求（RR）是否会被接受 - B 肯定有可能接受/拒绝 RR 而没有任何先前的 PR。

After searching quite a bit I found this pieceof information at www.w3.org (7.1.5):

经过一番搜索，我在 www.w3.org (7.1.5) 上找到了这条信息：

To protect resources against cross-origin requests that could not originate from certain user agents before this specification existed a preflight request is made to ensure that the resource is aware of this specification.

为了保护资源免受在本规范存在之前无法源自某些用户代理的跨域请求，需要进行预检请求以确保资源了解本规范。

I find this is the hardest to understand sentence ever. My interpretation (should better call it 'best guess') is that it's about protecting server B against requests from server C that is not aware of the spec.

我发现这是有史以来最难理解的句子。我的解释（最好将其称为“最佳猜测”）是关于保护服务器 B 免受来自不了解规范的服务器 C 的请求。

Can someone please explain a scenario / show a problem that PR + RR solves better than RR alone?

有人可以解释一个场景/展示一个 PR + RR 比单独 RR 解决的问题更好的问题吗？

采纳答案by Michael Iles

I spent some time being confused as to the purpose of the preflight request but I think I've got it now.

我花了一些时间对预检请求的目的感到困惑，但我想我现在已经明白了。

The key insight is that preflight requests are not a securitything. Rather, they're a not-changing-the-rulesthing.

关键的见解是预检请求不是安全问题。相反，它们是不改变规则的东西。

Preflight requests have nothing to do with security, and they have no bearing on applications that are being developed now, with an awareness of CORS. Rather, the preflight mechanism benefits servers that were developed withoutan awareness of CORS, and it functions as a sanity check between the client and the server that they are both CORS-aware. The developers of CORS felt that there were enough servers out there that were relying on the assumption that they would never receive, e.g. a cross-domain DELETE request that they invented the preflight mechanism to allow both sides to opt-in. They felt that the alternative, which would have been to simply enable the cross-domain calls, would have broken too many existing applications.

Preflight 请求与安全无关，它们与现在正在开发的应用程序无关，并具有 CORS 意识。相反，预检机制有益于在不了解 CORS 的情况下开发的服务器，并且它用作客户端和服务器之间的完整性检查，它们都可识别 CORS。CORS 的开发人员认为，有足够多的服务器依赖于他们永远不会收到的假设，例如他们发明了预检机制以允许双方选择加入的跨域 DELETE 请求。他们认为替代方案，即简单地启用跨域调用，会破坏太多现有的应用程序。

There are three scenarios here:

这里有三种情况：

1. Old servers, no longer under development, and developed before CORS. These servers may make assumptions that they'll never receive e.g. a cross-domain DELETE request. This scenario is the primary beneficiary of the preflight mechanism.Yes these services could already be abused by a malicious or non-conforming user agent (and CORS does nothing to change this), but in a world with CORS the preflight mechanism provides an extra 'sanity check' so that clients and servers don't break because the underlying rules of the web have changed.

2. Servers that are still under development, but which contain a lot of old code and for which it's not feasible/desirable to audit all the old code to make sure it works properly in a cross-domain world. This scenario allows servers to progressively opt-in to CORS, e.g. by saying "Now I'll allow this particular header", "Now I'll allow this particular HTTP verb", "Now I'll allow cookies/auth information to be sent", etc. This scenario benefits from the preflight mechanism.

3. New servers that are written with an awareness of CORS. According to standard security practices, the server has to protect its resources in the face of anyincoming request -- servers can't trust clients to not do malicious things. This scenario doesn't benefit from the preflight mechanism: the preflight mechanism brings no additional security to a server that has properly protected its resources.

1. 旧服务器，不再开发，在CORS之前开发。这些服务器可能会假设它们永远不会收到例如跨域 DELETE 请求。这个场景是预检机制的主要受益者。是的，这些服务可能已经被恶意或不符合标准的用户代理滥用（而 CORS 没有做任何改变），但在有 CORS 的世界中，预检机制提供了额外的“健全性检查”，以便客户端和服务器不会中断是因为网络的基本规则发生了变化。

2. 仍在开发中的服务器，但其中包含大量旧代码，并且审核所有旧代码以确保其在跨域世界中正常工作是不可行/不可取的。这种情况允许服务器逐步选择加入 CORS，例如通过说“现在我将允许此特定标头”、“现在我将允许此特定 HTTP 动词”、“现在我将允许 cookie/身份验证信息发送”等。这种情况受益于预检机制。

3. 以 CORS 意识编写的新服务器。根据标准的安全实践，面对任何传入的请求，服务器必须保护其资源——服务器不能相信客户端不会做恶意的事情。这种情况不会从预检机制中受益：预检机制不会为已正确保护其资源的服务器带来额外的安全性。

回答by Kevin Christopher Henry

What was the motivation behind introducing preflight requests?

引入预检请求的动机是什么？

Preflight requests were introduced so that a browser could be sure it was dealing with a CORS-aware server before sending certain requests. Those requests were defined to be those that were both potentially dangerous (state-changing) and new (not possible before CORS due to the Same Origin Policy). Using preflight requests means that servers must opt-in (by responding properly to the preflight) to the new, potentially dangerous types of request that CORS makes possible.

引入了预检请求，以便浏览器在发送某些请求之前可以确保它正在处理 CORS 感知服务器。这些请求被定义为具有潜在危险（状态改变）和新的（由于同源策略，在 CORS 之前不可能）。使用预检请求意味着服务器必须选择加入（通过正确响应预检）到 CORS 可能实现的新的、潜在危险的请求类型。

That's the meaning of this part of the specification: "To protect resources against cross-origin requests that could not originate from certain user agents before this specification existed a preflight request is made to ensure that the resource is aware of this specification."

这就是规范这一部分的含义：“为了保护资源免受在本规范存在之前无法源自某些用户代理的跨域请求，需要发出预检请求以确保资源了解本规范。”

Can you give me an example?

你能给我一个例子吗？

Let's imagine that a browser user is logged into their banking site at A.com. When they navigate to the malicious B.com, that page includes some Javascript that tries to send a DELETErequest to A.com/account. Since the user is logged into A.com, that request, if sent, would include cookies that identify the user.

让我们假设一个浏览器用户登录到他们的银行网站A.com。当他们导航到恶意程序时B.com，该页面包含一些 Javascript 尝试将DELETE请求发送到A.com/account. 由于用户已登录A.com，该请求（如果发送）将包含标识用户的 cookie。

Before CORS, the browser's Same Origin Policy would have blocked it from sending this request. But since the purpose of CORS is to make just this kind of cross-origin communication possible, that's no longer appropriate.

在 CORS 之前，浏览器的同源策略会阻止它发送此请求。但是由于 CORS 的目的只是使这种跨域通信成为可能，因此不再合适。

The browser couldsimply send the DELETEand let the server decide how to handle it. But what if A.comisn't aware of the CORS protocol? It might go ahead and execute the dangerous DELETE. It might have assumed that—due to the browser's Same Origin Policy—it could never receive such a request, and thus it might have never been hardened against such an attack.

浏览器可以简单地发送DELETE并让服务器决定如何处理它。但是如果A.com不知道 CORS 协议怎么办？它可能会继续执行危险的DELETE. 它可能会假设——由于浏览器的同源策略——它永远不会收到这样的请求，因此它可能永远不会被强化来抵御这样的攻击。

To protect such non-CORS-aware servers, then, the protocol requires the browser to first send a preflight request. This new kind of request is something that only CORS-aware servers can respond to properly, allowing the browser to know whether or not it's safe to send the actual DELETE.

为了保护此类不支持 CORS 的服务器，协议要求浏览器首先发送预检请求。这种新的请求只有 CORS 感知服务器才能正确响应，允许浏览器知道发送实际的DELETE.

Why all this fuss about the browser, can't the attacker just send a DELETErequest from their own computer?

为什么对浏览器这么大惊小怪，攻击者不能只DELETE从他们自己的计算机发送请求吗？

Sure, but such a request won't include the user's cookies. The attack that this is designed to prevent relies on the fact that the browser will send cookies (in particular, authentication information for the user) for the other domain along with the request.

当然可以，但这样的请求不会包含用户的 cookie。旨在防止的攻击依赖于浏览器将与请求一起发送其他域的 cookie（特别是用户的身份验证信息）这一事实。

That sounds like Cross-Site Request Forgery, where a form on site B.comcan POSTto A.comwith the user's cookies and do damage.

这听起来像跨站请求伪造，其中在网站上的表单B.com可以POST给A.com用户的cookies和进行破坏。

That's right. Another way of putting this is that preflight requests were created so as to not increase the CSRF attack surface for non-CORS-aware servers.

这是正确的。另一种说法是，创建预检请求是为了不增加非 CORS 感知服务器的 CSRF 攻击面。

But looking at the requirementsfor "simple" requests that don't require preflights, I see that POSTis still allowed. That can change state and delete data just like a DELETE!

但看的要求，对于不要求preflights“简单”的要求，我看POST还是允许的。可以像DELETE!

That's true! CORS does not protect your site from CSRF attacks. Then again, without CORS you are also not protected from CSRF attacks. The purpose of preflight requests is just to limit your CSRF exposure to what already existed in the pre-CORS world.

确实如此！CORS 不能保护您的站点免受 CSRF 攻击。再说一次，如果没有 CORS，您也无法免受 CSRF 攻击。预检请求的目的只是为了将您的 CSRF 暴露限制在 pre-CORS 世界中已经存在的内容。

Sigh. OK, I grudgingly accept the need for preflight requests. But why do we have to do it for every resource (URL) on the server? The server either handles CORS or it doesn't.

叹。好吧，我勉强接受了预检请求的需要。但是为什么我们必须对服务器上的每个资源（URL）都这样做呢？服务器要么处理 CORS，要么不处理。

Are you sure about that? It's not uncommon for multiple servers to handle requests for a single domain. For example, it may be the case that requests to A.com/url1are handled by one kind of server and requests to A.com/url2are handled by a different kind of server. It's not generally the case that the server handling a single resource can make security guarantees about all resources on that domain.

你确定吗？多个服务器处理单个域的请求并不少见。例如，可能存在请求A.com/url1由一种服务器A.com/url2处理而请求由不同类型的服务器处理的情况。通常情况下，处理单个资源的服务器不能对该域上的所有资源做出安全保证。

Fine. Let's compromise. Let's create a new CORS header that allows the server to state exactly which resources it can speak for, so that additional preflight requests to those URLs can be avoided.

美好的。我们妥协吧。让我们创建一个新的 CORS 标头，它允许服务器准确说明它可以代表哪些资源，从而可以避免对这些 URL 的额外预检请求。

Good idea! In fact, the header Access-Control-Policy-Pathwas proposed for just this purpose. Ultimately, though, it was left out of the specification, apparentlybecause some servers incorrectly implemented the URI specification in such a way that requests to paths that seemed safe to the browser would not in fact be safe on the broken servers.

好主意！事实上，标题Access-Control-Policy-Path就是为了这个目的而提出的。但最终，它被排除在规范之外，显然是因为某些服务器错误地实现了 URI 规范，以至于对浏览器似乎安全的路径的请求在损坏的服务器上实际上并不安全。

Was this a prudent decision that prioritized security over performance, allowing browsers to immediately implement the CORS specification without putting existing servers at risk? Or was it shortsighted to doom the internet to wasted bandwidth and doubled latency just to accommodate bugs in a particular server at a particular time?

这是一个将安全性置于性能之上的谨慎决定，允许浏览器立即实施 CORS 规范而不会使现有服务器面临风险吗？或者只是为了在特定时间适应特定服务器中的错误而注定互联网浪费带宽和双倍延迟是短视的吗？

Opinions differ.

意见不一。

Well, at the very least browsers will cache the preflight for a single URL?

好吧，至少浏览器会缓存单个 URL 的预检？

Yes. Though probably not for very long. In WebKit browsers the maximum preflight cache time is currently 10 minutes.

是的。虽然可能不会持续很长时间。在 WebKit 浏览器中，最大预检缓存时间目前为 10 分钟。

Sigh. Well, if I know that my servers are CORS-aware, and therefore don't need the protection offered by preflight requests, is there any way for me to avoid them?

叹。好吧，如果我知道我的服务器是 CORS 感知的，因此不需要预检请求提供的保护，有什么办法可以避免它们吗？

Your only real option is to make sure that you meet the requirementsfor "simple" requests. That might mean leaving out custom headers that you would otherwise include (like X-Requested-With), lying about the Content-Type, or more.

你唯一真正的选择是，以确保您符合要求的“简单”的请求。这可能意味着会遗漏您本来会包含的自定义标题（如X-Requested-With）、对 撒谎Content-Type，或更多。

Whatever you do, you must make sure that you have proper CSRF protections in place since the CORS specification does not address rejecting "simple" requests, including the unsafe POST. As the specification puts it: "resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery".

无论你做什么，你都必须确保你有适当的 CSRF 保护，因为 CORS 规范没有解决拒绝“简单”请求的问题，包括不安全的POST. 正如规范所说：“对于简单请求具有重要意义而不是检索的资源，必须保护自己免受跨站点请求伪造”。

回答by monsur

Consider the world of cross-domain requests before CORS. You could do a standard form POST, or use a scriptor an imagetag to issue a GET request. You couldn't make any other request type other than GET/POST, and you couldn't issue any custom headers on these requests.

在 CORS 之前考虑跨域请求的世界。您可以执行标准表单 POST，或使用script或image标签发出 GET 请求。除了 GET/POST 之外，您不能发出任何其他请求类型，并且不能对这些请求发出任何自定义标头。

With the advent of CORS, the spec authors were faced with the challenge of introducing a new cross-domain mechanism without breaking the existing semantics of the web. They chose to do this by giving servers a way to opt-in to any new request type. This opt-in is the preflight request.

随着 CORS 的出现，规范作者面临着在不破坏网络现有语义的情况下引入新的跨域机制的挑战。他们选择通过为服务器提供一种选择加入任何新请求类型的方式来实现这一点。此选择加入是预检请求。

So GET/POST requests without any custom headers don't need a preflight, since these requests were already possible before CORS. But any request with custom headers, or PUT/DELETE requests, doneed a preflight, since these are new to the CORS spec. If the server knows nothing about CORS, it will reply without any CORS-specific headers, and the actual request will not be made.

因此，没有任何自定义标头的 GET/POST 请求不需要预检，因为这些请求在 CORS 之前就已经可以实现了。但是任何带有自定义标头的请求或 PUT/DELETE 请求都需要预检，因为这些是 CORS 规范的新内容。如果服务器对 CORS 一无所知，它将在没有任何 CORS 特定标头的情况下进行回复，并且不会发出实际请求。

Without the preflight request, servers could begin seeing unexpected requests from browsers. This could lead to a security issue if the servers weren't prepared for these types of requests. The CORS preflight allows cross-domain requests to be introduced to the web in a safe manner.

如果没有预检请求，服务器可能会开始看到来自浏览器的意外请求。如果服务器没有为这些类型的请求做好准备，这可能会导致安全问题。CORS 预检允许以安全的方式将跨域请求引入 Web。

回答by Kornel

CORS allows you to specify more headers and method types than was previously possible with cross-origin <img src>or <form action>.

CORS 允许您指定比以前使用跨域<img src>或<form action>.

Some servers could have been (poorly) protected with the assumption that a browser cannot make, e.g. cross-origin DELETErequest or cross-origin request with X-Requested-Withheader, so such requests are "trusted".

假设浏览器无法发出（例如，跨域DELETE请求或带有X-Requested-With标头的跨域请求），某些服务器可能已经（较差）受到保护，因此此类请求是“受信任的”。

To make sure that server really-really supports CORS and not just happens to respond to random requests, the preflight is executed.

为了确保服务器真正支持 CORS 而不仅仅是响应随机请求，执行预检。

回答by Dylan Tack

Here's another way of looking at it, using code:

这是查看它的另一种方式，使用代码：

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Pre-CORS, the exploit attempt above would fail because it violates the same-origin policy. An API designed this way did not need XSRF protection, because it was protected by the browser's native security model. It was impossible for a pre-CORS browser to generate a cross-origin JSON POST.

在 CORS 之前，上面的漏洞利用尝试将失败，因为它违反了同源策略。以这种方式设计的 API 不需要 XSRF 保护，因为它受到浏览器本机安全模型的保护。CORS 之前的浏览器不可能生成跨域 JSON POST。

Now CORS comes on the scene – if opting-in to CORS via pre-flight was not required, suddenly this site would have a huge vulnerability, through no fault of their own.

现在 CORS 出现了——如果不需要通过飞行前选择加入 CORS，那么这个站点突然就会有一个巨大的漏洞，这不是他们自己的过错。

To explain why some requests are allowed to skip the pre-flight, this is answered by the spec:

为了解释为什么允许某些请求跳过预检，规范对此进行了回答：

A simple cross-origin request has been defined as congruent with those which may be generated by currently deployed user agents that do not conform to this specification.

一个简单的跨域请求已被定义为与那些可能由当前部署的不符合本规范的用户代理生成的请求一致。

To untangle that, GET is not pre-flighted because it is a "simple method" as defined by 7.1.5. (The headers must also be "simple" in order to avoid the pre-flight). The justification for this is that "simple" cross-origin GET request could already be performed by e.g. <script src="">(this is how JSONP works). Since any element with a srcattribute can trigger a cross-origin GET, with no pre-flight, there would be no security benefit to requiring pre-fight on "simple" XHRs.

为了解决这个问题，GET 没有预先执行，因为它是 7.1.5 定义的“简单方法”。（标题也必须“简单”，以避免飞行前）。这样做的理由是“简单”的跨域 GET 请求已经可以由 eg 执行<script src="">（这就是 JSONP 的工作方式）。由于任何具有src属性的元素都可以触发跨域 GET，无需预检，因此要求对“简单”XHR 进行预检没有安全优势。

回答by Hirako

I feel that the other answers aren't focusing on the reason pre-fight enhances security.

我觉得其他答案没有关注预战增强安全性的原因。

Scenarios:

场景：

1) With pre-flight. An attacker forges a request from site dummy-forums.com while the user is authenticated to safe-bank.com
If the Server does not check for the origin, and somehow has a flaw, the browserwill issue a pre-flight request, OPTION method. The server knows none of that CORS that the browser is expecting as a response so the browserwill not proceed (no harm whatsoever)

2) Without pre-flight. An attacker forges the request under the same scenario as above, the browser will issue the POST or PUT request right away, the server accepts it and might process it, this will potentially cause some harm.

1)飞行前。攻击者伪造来自 dummy-forums.com 站点的请求，同时用户通过 safe-bank.com 进行身份验证
如果服务器不检查来源，并且不知何故存在缺陷，浏览器将发出预检请求，OPTION方法。服务器不知道浏览器期望作为响应的 CORS 中的任何一个，因此浏览器将不会继续（没有任何伤害）

2）没有预飞行。攻击者在与上述相同的场景下伪造请求，浏览器会立即发出 POST 或 PUT 请求，服务器接受它并可能对其进行处理，这可能会造成一些危害。

If the attacker sends a request directly, cross origin, from some random host it's most likely one is thinking about a request with noauthentication. That's a forged request, but not a xsrf one. so the server has will check credentials and fail. CORS doesn't attempt to prevent an attacker who has the credentials to issue requests, although a whitelist could help reduce this vector of attack.

如果攻击者直接发送一个请求，跨起源，从一些随机的主机，那么它是最有可能的一个思考与请求没有身份验证。这是一个伪造的请求，但不是一个 xsrf 请求。所以服务器将检查凭据并失败。CORS 不会试图阻止拥有发出请求的凭据的攻击者，尽管白名单可以帮助减少这种攻击向量。

The pre-flight mechanism adds safety and consistency between clients and servers. I don't know if this is worth the extra handshake for every request since caching is hardy use-able there, but that's how it works.

预检机制增加了客户端和服务器之间的安全性和一致性。我不知道这是否值得为每个请求进行额外的握手，因为缓存在那里很难使用，但这就是它的工作原理。

回答by Oliver Weichhold

Additionally, for HTTP request methods that can cause side-effectson user data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request

此外，对于可能对用户数据产生副作用的HTTP 请求方法（特别是对于 GET 以外的 HTTP 方法，或者对于某些 MIME 类型的 POST 使用），规范要求浏览器“预检”请求

Source

来源

回答by Aditi Garg

Pre-flight requests are necessary for requests that can change state on the server. There are 2 types of requests -

对于可以更改服务器上的状态的请求，预飞行请求是必需的。有两种类型的请求 -

1) Calls that cannot change state on the server (like GET)- The user might get a response for the request (if the server does not check for origin) but if the requesting domain is not added to the response header Access-Control-Allow-Origin, the browser does not show the data to the user, i.e., the request is sent from the browser but the user isn't able to view/make use of the response.

1) 无法更改服务器状态的调用（如 GET）- 用户可能会收到请求的响应（如果服务器不检查来源）但如果请求域未添加到响应标头 Access-Control- Allow-Origin，浏览器不会向用户显示数据，即请求是从浏览器发送的，但用户无法查看/使用响应。

2) Calls that can change state on the server (like POST, DELETE)- Since in 1), we see that the browser doesn't block the request but the response, state changing calls should not be allowed to be made without prior checks. Such calls might make changes to a trusting server that does not check the origin of the calls (called Cross Site Request Forgery), even though the response to the browser might be a failure. For this reason, we have the concept of pre-flight requests that make an OPTIONS call before any state changing calls can be sent to the server.

2) 可以在服务器上改变状态的调用（如 POST、DELETE）- 由于在 1) 中，我们看到浏览器不会阻止请求而是响应，在没有事先检查的情况下，不允许进行状态改变调用. 此类调用可能会更改不检查调用来源的信任服务器（称为跨站点请求伪造），即使对浏览器的响应可能是失败的。出于这个原因，我们有飞行前请求的概念，在任何状态更改调用可以发送到服务器之前进行 OPTIONS 调用。

回答by Nipo

Aren't the preflighted requests about Performance? With the preflighted requests a client can quickly know if the operation is allowed before send a large amount of data, e.g., in JSON with PUT method. Or before travel sensitive data in authentication headers over the wire.

不是关于Performance的预检请求吗？使用预检请求，客户端可以在发送大量数据之前快速知道是否允许操作，例如，使用 PUT 方法的 JSON。或者在通过网络传输身份验证标头中的敏感数据之前。

The fact of PUT, DELETE, and other methods, besides custom headers, aren't allowed by default(They need explicit permission with "Access-Control-Request-Methods" and "Access-Control-Request-Headers"), that sounds just like a double-check, because these operations could have more implications to the user data, instead GET requests. So, it sounds like:

PUT、DELETE 和其他方法的事实，除了自定义标头之外，默认情况下是不允许的（它们需要“Access-Control-Request-Methods”和“Access-Control-Request-Headers”的明确许可），听起来就像双重检查一样，因为这些操作可能会对用户数据产生更多影响，而不是 GET 请求。所以，听起来像：

"I saw that you allow cross-site requests from http://foo.example, BUT are you SURE that you'll allow DELETE requests? Did you consider the impacts that these requests might cause in the user data?"

“我看到您允许来自http://foo.example 的跨站点请求，但您确定允许 DELETE 请求吗？您是否考虑过这些请求可能对用户数据造成的影响？”

I didn't understand the cited correlation between the preflighted requests and the old servers benefits. A Web Service that was implemented before CORS, or without a CORS awareness, will never receive ANY cross-site request, because first their response won't have the "Access-Control-Allow-Origin" header.

我不明白预检请求和旧服务器的好处之间引用的相关性。在 CORS 之前实现或没有 CORS 感知的 Web 服务将永远不会收到任何跨站点请求，因为首先它们的响应不会具有“Access-Control-Allow-Origin”标头。

回答by AndreKR

In a browser supporting CORS, readingrequests (like GET) are already protected by the same-origin policy: A malicious website trying to make an authenticated cross-domain request (for example to the victim's internet banking website or router's configuration interface) will not be able to read the returned data because the bank or the router doesn't set the Access-Control-Allow-Originheader.

在支持 CORS 的浏览器中，读取请求（如 GET）已经受到同源策略的保护：尝试发出经过身份验证的跨域请求（例如到受害者的网上银行网站或路由器的配置界面）的恶意网站不会能够读取返回的数据，因为银行或路由器没有设置Access-Control-Allow-Origin标头。

However, with writingrequests (like POST) the damage is done when the request arrives at the webserver.* A webserver could check the Originheader to determine if the request is legit, but this check is often not implemented because either the webserver has no need for CORS or the webserver is older than CORS and is therefore assuming that cross-domain POSTs are completely forbidden by the same-origin policy.

然而，写入请求（如 POST）会在请求到达网络服务器时造成损坏。* 网络服务器可以检查Origin标头以确定请求是否合法，但这种检查通常不会实施，因为网络服务器不需要对于 CORS 或网络服务器比 CORS 更旧，因此假设跨域 POST 完全被同源策略禁止。

That is why webservers are given the chance to opt-in into receiving cross-domain write requests.

这就是网络服务器有机会选择接收跨域写入请求的原因。

_{* Essentially the AJAX version of CSRF.}

_{*本质上是CSRF的AJAX版本。}