我相信我终于找到了CORS及其动机。
简而言之，我了解源自 original.com 的脚本试图从 other.com <请求资源 < / strong>由于信息泄露而存在潜在风险（对于所有各方：user，original.com和other.com）;这就是CORS背后的动机。我的问题与此无关。
CORS要求 other.com 选择/同意源自 original.com 的脚本的请求。
我需要一段时间才能理解，因为我有一种直觉，我不得不反对。我的直觉是它应该选择加入/同意交叉 original.com （和不 other.com ） -origin request。
认为 original.com 是用户信任的域（毕竟，用户首先访问 original.com ）。因此，浏览器（CORS的执行者）应该信任用户信任的任何人。
e.g。
如果 original.com 表示信任 other.com ， ads.com 和/或 tracker.com 然后继续并允许他们的请求。但是，如果随后 ads.com 返回一个脚本，该脚本会从 shadows.com （ original.com 不请求某些内容>信任）然后阻止它。
目前，如果CORS接受来自 original.com 的请求，则会导致浏览器询问 shadows.com 。而且我想象 shadows.com 是皮革扶手椅上的反派，说'为什么是，绝对'＆gt; :)。
答案 0 :(得分：0)
简而言之，这是因为数据是从其他域下载的。在您的示例中，other.com保存数据，并可以决定与谁共享该数据的人（起源）。
你提到的那种信任也顺便提一下。当用户在上面的例子中访问original.com时，他相信original.com只会让他从那些被认为可以从original.com的开发者那里下载数据的域下载东西。但是，当来自访问不同站点（original.com）的用户时，这些其他来源（other.com等）是否想要提供请求，这是其他域的决定。