我读过一篇使用 Cors-Anywhere 的文章提出一个示例 url 请求，这让我想到同源策略是多么容易被绕过。
虽然浏览器会阻止你直接访问error，在没有通过preflight请求时一并取消请求，但是一个简单的节点服务器不需要遵守这样的规则，可以作为代理使用。
所有需要做的就是将 'https://cors-anywhere.herokuapp.com/' 附加到恶意脚本中请求的 url 的开头，瞧，你没有不需要通过 CORS。
作为sideshowbarker pointed out ，部署您自己的 Cors-Anywhere 服务器需要几分钟时间。
这不会让 SOP 作为一种安全措施变得毫无意义吗？
最佳答案
SOP 的目的是按来源隔离浏览器中存储的数据。如果您从 domain1.tld 获得 cookie(或者它在浏览器存储中为您存储数据)，domain2.tld 上的 Javascript 将无法获得访问权限。这不能被任何服务器端组件规避，因为该组件仍然无法以任何方式访问。如果没有 SOP，恶意网站就可以在您的浏览器中读取其他网站存储的任何数据。
正如您正确指出的那样，这也与 CORS 相关。通常，您的浏览器不会收到来自与它正在运行的页面来源不同的来源的 javascript 请求的响应。这样做的目的是，如果它有效，您可以从用户登录的站点获取信息。如果您通过 Cors-Anywhere 发送它，您将无法发送其他站点的用户 session cookie，因为你仍然没有访问权限，请求将作为代理发送到你自己的服务器。
Cors-Anywhere 重要的是未经身份验证的 API。某些 API 可能会检查原始 header 并仅响应其自己的客户端域。在这种情况下，当然，Cors-Anywhere 可以添加或更改 CORS header ，以便您可以从自己的托管客户端查询它。但 SOP 的目的并不是为了防止这种情况，即使在这种情况下，API 所有者也更容易将您的请求列入黑名单或限制您的请求，因为它们都由您的服务器代理。
简而言之，SOP 和 CORS 不是我认为您所指意义上的访问控制机制。它们的目的是防止和/或安全地允许对某些资源的跨源请求，但它们并不意味着例如阻止服务器端组件发出任何请求，或者例如尝试验证您的客户端 javascript 本身(这是技术上不可能)。
关于security - 同源策略容易规避？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63435310/