跨域资源共享是一种机制，允许网页向另一个域名发起XMLHttpRequest（来自Wikipedia）。
我已经在研究CORS几天了，我认为我对所有东西的工作原理都有了很好的理解。
所以我的问题不是关于CORS / 预检如何工作的，而是关于提出预检作为新请求类型背后的原因。我看不出服务器A需要向服务器B发送预检（PR）来查明是否接受真实请求（RR）的任何原因 - B可以在没有任何先前PR的情况下接受/拒绝RR。
在搜索了很多内容之后，我在www.w3.org（7.1.5）找到了这段信息：
为了保护资源免受跨源请求的攻击，这些请求在此规范之前无法从某些用户代理发起，需要进行预检请求以确保该资源意识到此规范的存在。我曾经对预检请求的目的感到困惑，但现在我想我理解了。关键在于，预检请求不是一个安全的问题。相反，它们是一个不改变规则的问题。
预检请求与安全无关，对于那些意识到CORS的应用程序来说也没有影响。相反，预检机制有益于那些没有意识到CORS的服务器，并且它在客户端和服务器之间起到了一个合理性检查的作用，以确保它们都具备CORS意识。CORS的开发人员认为，有足够多的服务器依赖于这样一种假设，即它们永远不会接收到跨域DELETE请求，他们发明了预检机制，以允许双方选择加入。他们认为，另一种选择——仅仅启用跨域调用——将会破坏太多现有的应用程序。
这里有三种情况:
旧服务器，不再开发，并且在CORS出现之前开发。这些服务器可能会做出假设，即它们永远不会收到例如跨域DELETE请求。 这种情况是预检机制的主要受益者。 是的，这些服务已经可以被恶意或不合规的用户代理滥用（CORS对此毫无作为），但在CORS的世界里，预检机制提供了额外的“合理性检查”，以使客户端和服务器不会因为Web的基本规则发生变化而中断。
仍在开发中的服务器，但其中包含大量旧代码，并且审核所有旧代码以确保其在跨域环境下正常工作是不可行/不可取的。这种情况允许服务器逐步加入CORS，例如通过说“现在我将允许这个特定的标头”，“现在我将允许这个特定的HTTP动词”，“现在我将允许发送cookie/auth信息”等。 这种情况受益于预检机制。
新的服务器编写时意识到CORS。根据标准安全实践，服务器必须在面对任何传入请求时保护其资源--服务器不能相信客户端不会做恶意的事情。 这种情况不受预检机制的好处：预检机制对于已正确保护其资源的服务器不会带来额外的安全性。
什么是引入预检请求的动机？
引入预检请求是为了让浏览器在发送某些请求之前确定它正在处理一个CORS感知服务器。这些请求被定义为潜在危险（改变状态）且新的（由于同源策略，在CORS之前不可能）。使用预检请求意味着服务器必须选择加入（通过正确响应预检请求）到CORS使得可能的新的、潜在危险的请求类型中。
这就是原始规范this part的含义：“为了保护资源免受跨域请求的影响，这些请求在此规范出现之前无法从某些用户代理发起，因此需要进行预检请求以确保该资源已经意识到此规范。”
你能给我一个例子吗？
假设浏览器用户已登录其银行网站
A.com。当他们导航到恶意的 B.com 时，该页面包括一些 JavaScript，试图向 A.com/account 发送一个 DELETE 请求。由于用户已登录 A.com，如果发送该请求，它将包括标识用户的 cookie。DELETE 并让服务器决定如何处理它。但是，如果 A.com 不知道 CORS 协议怎么办？它可能会继续执行危险的 DELETE。它可能已经假定由于浏览器的同源策略，它永远不会收到这样的请求，因此可能从未针对这种攻击进行过硬化。DELETE请求。
为什么要大费周折涉及到浏览器呢？攻击者不能直接从他们自己的计算机发送DELETE请求吗？
当然可以，但这样的请求不会包含用户的cookies。这个设计旨在防止一种攻击行为，该攻击行为依赖于浏览器将来自其他域的cookie（特别是用户的身份验证信息）与请求一起发送。
听起来像是跨站请求伪造(Cross-Site Request Forgery)，其中站点B.com上的表单可以提交到A.com，并使用用户的cookie造成破坏。
没错。换句话说，预检请求的创建是为了不增加对不支持CORS的服务器的CSRF攻击面。
但是POST被列为不需要预检请求的方法。像DELETE一样，它可以改变状态并删除数据！
没错！CORS不能保护您的站点免受CSRF攻击。但是，如果没有CORS，您也无法免受CSRF攻击。预检请求的目的只是将您的CSRF暴露限制在预CORS世界中已经存在的范围内。
唉。好吧，我勉强接受预检请求的必要性。但是为什么我们必须为服务器上的每个资源（URL）都这样做呢？服务器要么处理CORS，要么不处理。
你确定吗？多个服务器为单个域处理请求并不罕见。例如，可能情况是对A.com/url1的请求由一种服务器处理，而对A.com/url2的请求由另一种服务器处理。通常情况下，处理单个资源的服务器无法对该域上的所有资源提供安全保证。
好的。让我们妥协，创建一个新的CORS头，允许服务器明确说明它可以代表哪些资源，以避免对这些URL进行额外的预检请求。
好主意！事实上，头文件Access-Control-Policy-Path就是为此目的而提出的。不过，最终该规范被省略了，显然是因为一些服务器错误地实现了URI规范，以致于浏览器认为路径安全，但在这些有问题的服务器上却并非如此。
这是一个明智的决定，优先考虑安全性，使浏览器可以立即实现CORS规范，而不会让现有的服务器面临风险吗？还是说这是短视的，为了适应特定时间的某个服务器中的错误而浪费带宽和加倍延迟，从而注定了互联网的浪费？
意见不一。
那么至少浏览器会为单个URL缓存预检吗？
是的。不过可能时间不会很长。在WebKit浏览器中，预检请求缓存的最大时间为目前为10分钟。X-Requested-With），更改Content-Type或其他操作。
无论你做什么，都必须确保你有适当的CSRF保护措施，因为CORS不会阻止所有不安全的请求。正如原始规范所述：“除了检索之外，简单请求具有其他含义的资源必须保护自己免受跨站点请求伪造的攻击。”
B.com页面的Javascript触发对A.com的请求。 - Kevin Christopher HenryDELETE请求，服务器可能会执行该请求。这就是我们试图通过预检来防止的问题。对于安全请求，我们不必保护服务器，因此在这种情况下不需要进行预检，浏览器可以仅依靠头部信息来决定如何处理请求。 - Kevin Christopher Henryscript或image标签发出GET请求。除了GET/POST，你无法进行任何其他类型的请求，并且在这些请求中不能发出任何自定义头部。我认为其他答案没有关注预检请求增强安全性的原因。
场景：
1）使用预检请求。攻击者伪造了一个来自dummy-forums.com网站的请求，而用户已通过safe-bank.com进行身份验证。如果服务器不检查来源，并且存在缺陷，则浏览器将发出预检请求，即OPTION方法。服务器不知道浏览器期望作为响应的CORS，因此浏览器不会继续（完全没有危害）。
2）不使用预检请求。在与上述情况相同的情况下，攻击者伪造请求，浏览器将立即发出POST或PUT请求，服务器接受并可能处理该请求，这可能会导致一些危害。
如果攻击者直接从某个随机主机发出跨源请求，那么很可能是在考虑一个没有身份验证的请求。这是一个伪造的请求，但不是xsrf攻击。因此，服务器将检查凭据并失败。尽管白名单可以帮助减少此攻击向量，但CORS并不试图防止具有凭据发出请求的攻击者。
预检机制增加了客户端和服务器之间的安全性和一致性。我不知道这是否值得每个请求额外进行一次握手，因为缓存在那里很难使用，但这就是它的工作原理。
这是另一种看待它的方式，使用代码：
<!-- 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>
在CORS出现之前，上述的攻击尝试会失败，因为它违反了同源策略。设计成这样的API不需要XSRF保护，因为它受到浏览器本地安全模型的保护。在Pre-CORS时代，浏览器无法生成跨源JSON POST。
现在，如果不需要通过预检请求来选择支持CORS，则突然间该网站将具有巨大的漏洞，而这并非他们自己的过错。
要解释为什么允许跳过预检请求的一些请求，可以通过规范回答：
已定义简单跨源请求与当前部署的不符合此规范的用户代理可能生成的那些一致。
简单的跨源GET请求不需要预检请求，因为它是由7.1.5定义的“简单方法”。 （头也必须是“简单的”，以避免预检请求）。这样做的理由是，例如，可以通过<script src="">（这就是JSONP的工作方式）执行“简单”的跨源GET请求。由于带有src属性的任何元素都可以触发没有预检请求的跨源GET请求，因此在“简单”XHR上要求预检请求没有安全性好处。
Access-Control-Allow-Origin头。
然而，对于写入请求（如POST），当请求到达Web服务器时，损害已经造成。* Web服务器可以检查Origin头以确定请求是否合法，但是这种检查通常没有实现，因为要么Web服务器不需要CORS，要么Web服务器比CORS旧，因此假定跨域POST完全被同源策略禁止。
这就是为什么Web服务器有机会选择加入接收跨域写请求的原因。
* 本质上是CSRF的AJAX版本。