CORS 如何至少为用户提供一些安全性？

Question

首先道歉：这对我来说就像一个“愚蠢”的问题，我想我很快就会后悔问这个问题......但我现在无法弄清楚，因为我的思想似乎陷入了错误的轨道. 所以请耐心等待并帮助我：

我的理解是，“同源”对于 Web 服务来说是一种痛苦，作为回应，CORS 放宽了限制，使 Web 服务合理工作，但仍然为用户提供了不错的安全性。我的问题是 CORS 是如何做到这一点的？

假设用户访问网站A，该网站提供了向网站Z发出Web服务请求的代码。但我已经闯入并破坏了网站Z，并将其变成了攻击站点。我很快让它对所有 CORS 请求做出积极响应（标头添加 Access-Control-Allow-Origin: "*"）。很快，用户的电脑就被我来自 Z 的攻击所颠覆。

在我看来，用户从未访问过ž直接，什么都不知道绕Z轴的存在，从来没有“批准” Z.它在唱到后，在我看来-甚至变得known-有什么网站A能阻止它这样做（短的打算离线本身:-)。难道安全问题不会要求 A 证明 Z，而不是 Z 证明 A？我错过了什么？

Answer 1

我也在研究这个问题，因为我的思维过程与你的相似。根据我的新理解：CORS 不提供安全性，它绕过它来提供功能。浏览器一般不允许跨域请求；如果您访问 shady.com，并且那里有一个脚本尝试使用您计算机上的 cookie访问bank.com访问bank.com ，那么 shady.com 的脚本将能够使用该 cookie 在bank.com 上执行操作来冒充您。为了防止这种情况，bank.com 不会将其 API 标记为启用了 CORS，这样当 shady.com 的脚本开始 HTTP 请求时，浏览器本身会阻止该请求。

因此，同源可以保护用户免受自身侵害，因为他们不知道周围有什么 auth cookie；CORS 允许代表用户拥有资源的服务器将 API 标记为可从其他站点的脚本访问，这将导致浏览器忽略其自己的跨域保护策略。

（有更明白的人请根据需要补充或更正！）

Answer 2

CORS 对安全没有任何作用。它确实允许销售网络字体的人决定哪些网站可以轻松访问他们的字体。这几乎是唯一的用例。

用户和引入 CORS 之前一样不知道。请记住，跨源请求在 CORS 之前就可以工作（人们经常抱怨你必须填充 jQuery 才能在 IE 中获得 CORS 支持......但在 IE 中你可以只发出请求并获得响应，而不需要任何额外的努力。它刚刚工作）。

一般来说，信任模型是倒退的。正如其他人所说，您通过引用其他一些网站来暗示信任......所以给我那些该死的数据！