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