关键的见解是，预检请求不是一个安全的事情。相反，他们是一个不改变规则的事情。

预检请求与安全无关，并且它们对于现在正在开发的应用程序没有影响，意识到CORS。相反，预检机制有利于在没有意识到CORS的情况下开发的服务器，并且它用作客户端和服务器之间的可靠性检查，它们都是CORS感知的。 CORS的开发者认为有足够的服务器，依赖于他们永远不会接收的假设，例如。跨域DELETE请求，他们发明了预检机制以允许双方选择加入。他们认为，替代方案，这将是简单地启用跨域调用，将打破太多的现有应用程序。

这里有三种情况：

>旧服务器，不再处于开发中，并在CORS之前开发。这些服务器可以假设他们永远不会接收。跨域DELETE请求。这种情况是预检机制的主要受益者。是的，这些服务可能已经被恶意或不合格的用户代理滥用(并且CORS没有改变这一点)，但是在一个使用CORS的世界中，预检机制提供了一个额外的“健康检查”，使客户端和服务器不因为网络的基本规则已经改变。>仍在开发中的服务器，但它们包含大量旧代码，因此对于所有旧代码进行审计以确保其在跨域环境中正常工作是不可行/不可取的。这种情况允许服务器逐步选择加入CORS，例如通过说“现在我将允许这个特定的头”，“现在我将允许这个特定的HTTP动词”，“现在我将允许发送cookie / auth信息”等。这种情况下从预检机制。>使用CORS意识书写的新服务器。根据标准的安全实践，服务器必须在任何传入请求面前保护其资源 – 服务器不能信任客户端不做恶意的事情。此方案不会从预检机制中受益：预检机制不会对已正确保护其资源的服务器带来额外的安全性。