首先道歉：这对我来说就像一个“愚蠢”的问题，我希望我很快就会后悔甚至不敢问......但是我现在无法理解，因为我的思绪似乎陷入困境错误的车辙。所以请耐心地帮助我：
我的理解是“同源”是Web服务的PITB，作为回应，CORS放宽了足以使Web服务合理运行的限制，但仍然为用户提供了良好的安全性。我的问题是CORS究竟是如何做到的？
假设用户访问网站A，网站A提供向网站Z发出网络服务请求的代码。但是我已经闯入并破坏了网站Z，并将其变成了攻击网站。我很快就对所有CORS请求作出了积极响应（标题添加了Access-Control-Allow-Origin：“*”）。很快，用户的计算机被Z的攻击破坏了。
在我看来，用户从未直接访问过Z，对Z的存在一无所知，也从未“批准”过Z.而且在我看来 - 即使在知道破解之后 - 还有 nothing 网站A可以阻止它（没有离线本身:-)。安全问题是否要求A证明Z，而不是Z证明A？我错过了什么？
答案 0 :(得分：2)
CORS对安全没有任何作用。它确实允许销售网络字体的人决定哪些网站可以轻松访问他们的字体。这几乎是唯一的用例。
用户与引入CORS之前一样没有意识到。请记住，在CORS之前，交叉原始请求曾经工作过（人们经常抱怨你必须使用jQuery来获取IE中的CORS支持......但是在IE中，你可以直接提出请求并获得响应而无需任何额外的努力。它刚刚起作用。）
一般来说，信任模型是倒退的。正如其他人所说，你通过引用其他网站暗示了信任......所以给我一些惊人的数据吧！
答案 1 :(得分：1)
我也正在研究这个，因为我的思维过程与你的相似。根据我的新理解：CORS不提供安全性，它绕过它来提供功能。浏览器通常不允许跨源请求;如果你去shady.com，并且有一个脚本尝试使用你机器上的cookie 访问bank.com ，那么shady.com的脚本就可以在bank.com上执行操作了。使用该cookie来冒充你。为了防止这种情况，bank.com不会将其标记为启用CORS的API，因此当shady.com的脚本开始HTTP请求时，浏览器本身会阻止该请求。
因此，同源保护用户不会自己，因为他们不知道auth cookie正在铺设什么; CORS允许代表用户拥有资源的服务器将API标记为可从其他站点的脚本访问，这将导致浏览器忽略其自己的跨源保护策略。
（任何明白这一点的人，请根据需要添加或更正！）
答案 2 :(得分：0)
CORS 通过告知用户浏览器允许或不允许查看请求响应来保护接收请求的网站（在您的示例中为 Z）免受发出请求的网站（在您的示例中为 A）。< /p>
当 JavaScript 应用程序要求浏览器向与自己不同的源发出 HTTP 请求时，浏览器不知道这两个源之间是否有相互协议来进行此类调用。当然，如果请求来自源 A，那么 A 同意（如果 Z 是恶意的，A 对其用户负责），但是接收者 Z 同意吗？浏览器知道的唯一方法是询问 Z，它通过实际执行请求来做到这一点。除非 Z 明确允许 A 接收响应，否则浏览器不会让 A 的应用程序读取它。
你说得对，CORS 的唯一作用就是放宽同源策略。在此之前，允许跨域请求，并且浏览器会自动包含它对目的地的 cookie，即它会向 Z 发送一个经过身份验证的请求。这意味着，在没有同源策略的情况下，A 可以像用户一样浏览 Z，查看它的数据等。同源修复了这个非常严重的安全漏洞，但是因为某些服务仍然需要使用跨源请求有时，会创建 CORS。
请注意，CORS 不会阻止请求被发送，因此如果 A 的 JS 应用向 Z 发送请求，命令它将用户的所有资金发送到某个帐户，Z 将收到此请求里面的所有饼干。这称为跨站点请求伪造 (CSRF)。有趣的是，针对此类攻击的主要防御是基于 CORS。它包括在请求中需要一些只能通过跨域请求获得的秘密值（“CSRF 令牌”），如果 A 不在 Z 的授权列表中，则无法获得。 如今，同站 cookie 可以也可以使用，它们更易于管理，但不能跨域工作。