问题描述
我读过一篇使用Cors-Anywhere发出示例url请求的文章，这使我想到了绕过“同源起源策略”的难易程度。
尽管浏览器阻止您直接访问错误，并且在未通过预检请求时完全取消了该请求，但是简单的节点服务器不需要遵守此类规则，并且可以用作代理。
所有要做的就是在恶意脚本和Voila中将'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发送信息，则您将无法为另一个站点发送用户的会话cookie，因为您仍然没有访问权限，请求将作为代理发送到您自己的服务器。
Cors-Anywhere重要的地方是未经身份验证的API。某些API可能会检查原始标头，并且仅响应其自己的客户端域。在这种情况下，请确保Cors-Anywhere可以添加或更改CORS标头，以便您可以从自己的托管客户端中查询它。但是SOP的目的并不是防止这种情况发生，即使在这种情况下，API所有者也很容易将您的请求列入黑名单或限制您的请求，因为它们都由您的服务器代理。
简而言之，按照我认为您的意思，SOP和CORS并不是访问控制机制。它们的目的是防止和/或安全地允许对某些资源的跨域请求，但是它们的目的不是例如防止服务器端组件发出任何请求，也不是例如尝试对客户端javascript本身进行身份验证（在技术上不可能）。