浏览器中有一个相同的来源策略，以确保坏网站不会从 Facebook 读取您的数据。但似乎它试图解决的唯一问题是 cookie 会随请求自动发送对用户进行身份验证的请求（+ 可能是其他一些身份验证方案，如基本或证书）。
所以我的问题是：如果浏览器不会自动发送带有此请求的所有 http auth 详细信息和 cookie，我们真的需要此策略吗？
也许最好的方法是默认允许跨域，但要确保不传输此信息（cookie、http auth）。无论如何，如果需要跨站点请求，我们现在可以生成基于令牌的 API，等等。并且 3d 方调用者需要以相同的方式获取令牌，这样就不需要 CORS。
不，同源政策还可以防止：
所以我的问题是：如果浏览器不会自动发送带有此请求的所有 http auth 详细信息和 cookie，我们真的需要此策略吗？
是的，出于上述原因，我们确实需要它。
它可以像那样工作，但由于向后兼容性的原因，现在不行。它会破坏太多东西，突然改变世界上大多数网络所基于的标准。
无论如何，如果整个窗口被重定向，会发生什么？例如，如果存在可以通过CSRF使用 GET 方法利用的敏感功能，攻击者可以简单地将整个页面重定向到https://example.com/delete_users以执行攻击。
在这种情况下，浏览器如何知道不发送 cookie？看来您唯一能实现的就是使规则更加复杂，而复杂性是安全的敌人。
要添加到 SilverlightFox 的出色答案：
即使如果浏览器没有发送HTTP认证头，并与跨域请求的Cookie（这是不实际的，因为页数太多依靠这一点），跨域请求仍然是危险的，因为请求可以擅自头甚至返回私人信息.
本质上，问题在于客户端浏览器可能使用其他授权机制访问私有资源。例如：
在这些情况下，去除特定的 HTTP 标头是不够的。
顺便说一句，故意不为某些请求发送 cookie 的想法已通过SameSitecookie实现。SameSitecookie 不会随跨域请求一起发送。
为了避免提到的向后兼容性问题，SameSitecookie 是“选择加入”的——要创建 SameSite cookie，服务器必须SameSite在设置 cookie 时指定。没有此属性的 Cookie 会继续为跨域请求发送，因此同源策略仍然很重要。