我将首先说许多人误解了同源政策以及CORS带来的内容。

这里已经有一些投票赞成的答案指出，同源策略会阻止跨站点请求，因此会阻止CSRF。不是这种情况。SOP 所做的只是防止响应被另一个域（又名来源）读取。这与“经典”CSRF 攻击是否成功无关。

我所说的“经典”指的是在 CORS 出现之前可能出现的请求类型。也就是说，可以通过 HTML 表单以及 XHR 发送的请求类型（例如，没有自定义标头的 GET 或 POST）。

SOP 与“经典”CSRF 一起发挥作用的唯一一次是防止任何令牌被不同的域读取。

当然，现在我们有了 CORS，并且各种跨域请求都是可能的，例如 PUT 和 DELETE，CORS 实际上通过要求预飞行来防止这些请求。然而，一般来说，CORS 并没有提供更大的净收益，因为这个功能首先可用的原因是 CORS。

CORS 所做的只是在 SOP 处于活动状态时放松它。它不会增加安全性（除了可能允许标准化跨域资源共享并防止开发人员使用 JSONP 之类的东西引入缺陷），它只是允许发生一些异常。一些支持部分 CORS 的浏览器允许跨站点 XHR 请求（例如 IE 10 和更早版本），但是它们不允许附加自定义标头。在支持 CORS 的浏览器中，Origin无法设置标头，以防止攻击者进行欺骗。

我提到域是不同的起源。在谈论 AJAX 请求时，来源也可能因端口和协议而异（与 cookie 不同）。

最后，以上所有内容都与直接来自攻击者的伪造请求无关，例如 curl。请记住，攻击者需要使用受害者的浏览器进行攻击。他们需要浏览器自动发送其 cookie。这不能通过直接 curl 请求来实现，因为这只会在这种类型的攻击场景（称为“客户端攻击”的类别）中对攻击者进行身份验证。

CORS 的好处是它允许您的域允许从另一个受信任的域进行读取。因此，如果您有http://data.example.org，您可以设置响应标头以允许http://site.example.com发出 AJAX 请求并从您的 API 检索数据。

你把事情搞混了。CORS 并不是要保护您的应用程序免受精心制作的 http 请求的影响，而是要通过检查哪些站点可以访问您的资源来保护您免受某种“窃取”用户的 cookie 或访问令牌的攻击。

它主要用于保护您的服务器/应用程序免受跨站点请求伪造，其中恶意站点将代表用户发出请求，可能具有恶意意图（凭证更改，资金转移......），利用以下事实：浏览器将发送所有仍然有效且对您的站点有效的登录和会话 cookie。

如果 CORS 配置正确，攻击者站点的 ajax 请求将被拒绝，因为默认情况下，它只接受同一站点的请求。

这并不意味着您不应该清理您的输入，而只是保护您免受某种类型的 CSFR 攻击。如果攻击者获得您用户的 cookie/访问令牌，他无论如何都会被授予访问权限，这就是为什么大多数身份验证过程应该使用 SSL作为额外的保护层。

PS：这假设您的用户使用的浏览器是最新的，没有缺陷并且正确地遵守相同的来源政策。

编辑：至于预检请求，这是确保站点被授予访问权限的附加措施，并且并非针对所有跨域请求完成

在过去的几天里，我一直在阅读有关 CORS 的内容，并且在很多地方都提到了它，因为它是一种“安全”功能，可以帮助世界免受跨域伪造。

您要么误解了 CORS 的好处，要么您可能在一些由开发人员撰写的业余博客中读到了这一点，他们更担心如何使其工作而不是如何使其安全（如果您理解我的意思），因为 CORS 宁愿让当您使用带有以下标头的 CORS 打开来自攻击者来源的跨域请求时，您的 Web 应用程序容易受到此类攻击 ( CSRF )：Access-Control-Allow-Origin: *

CORS 如何提供帮助，它有什么好处？

CORS 的诞生是为了减轻SOP对可信请求的限制。但问题正是从这种信任开始的。例如，攻击者可以通过 GET 和 POST 方法伪造恶意请求，从而通过源头造成伤害，甚至可能会暴露您的DNS 重新绑定

将所有这些总结如下是否有意义：

• SOP（单一来源策略）确保 CSRF 攻击不能在现代、最新的浏览器中进行，因为攻击者必须从另一个域发布。

• CSRF（跨站点请求伪造）令牌确保不能在浏览器之外发出危险的 POST 请求（SOP 不适用的地方，例如使用curl），因为它们无法访问共享之外的用户 cookie 中的身份验证数据浏览器体验。

• CORS（跨域资源共享）可用于放宽对浏览器的 SOP 限制，但前提是资源服务器通过 CORS 标头允许它。因此，如果使用不当，它实际上可能会削弱安全性。