跨域资源共享（CORS）HTTP头的重点

Question

以下MDN文章讨论了CORS头：跨源资源共享（CORS） 我的问题很基础：对于一个简单请求（非预检请求），如果我们无论如何都会通过HTTP响应发送所请求的资源，那么在服务器端添加CORS头的意义是什么呢？我原以为CORS头的作用是为了让UA只有在服务器允许时才能接收到请求的资源。

是否根据请求方直接发送或不发送资源会更容易呢？

- Magnus

---

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. - mplungjan

一个很好的例子是<img>标签和它所涉及到的HTTP请求。浏览器知道这与向同一URL发出XHR的区别，但服务器不知道。 - Pointy

@Pointy 只是挑剔一下（希望不会给Magnus带来额外的困惑），受影响的不仅仅是XHR。您可以在页面上放置一个跨域的<img>，并且浏览器知道它是否具有适当的CORS标头。例如，如果您将该图像绘制到画布上，则它将起作用，但您将无法以编程方式读取该画布。 - Brad

@Brad 是的，那也是正确的。重点在于服务器不知道浏览器为什么发起了 HTTP 请求，但浏览器知道并且根据 CORS 标头（或它们的缺失）知道该执行什么操作。 - Pointy

@Brad和Pointy，感谢你们的有益评论。我在下面ADyson的答案中添加了一条评论，进一步阐述了我所困惑的问题。浏览器是否可以以某种有效的方式隐藏/隐藏数据，使其对浏览器的作者/用户不可见？ - Magnus

Answer 1

对于同源请求（不需要CORS），我同意添加CORS头部没有太大的意义，但同样也不会有任何伤害。

对于跨域请求，头部告诉浏览器页面是否被允许访问资源。

需要注意的是，这是由浏览器控制的，因为CORS是一种特定于浏览器的技术。CORS限制不适用于非浏览器HTTP客户端。服务器不直接拒绝访问，只是添加标头，指示浏览器在给定场景下应该如何处理响应——即是否应该覆盖浏览器实现的正常“同源”策略，并允许访问资源。

此外，您询问是否服务器拒绝根据请求的客户端类型访问资源更容易。 HTTP的设计方式意味着客户端是谁或什么并不重要，只要它符合标准。猜测客户端的性质的唯一方法是读取User-Agent字符串，但这很容易欺骗，因此您永远无法在服务器上使用它来实现任何与安全相关的内容。标准中也没有任何强制要求允许您知道请求是否由AJAX发出（因为只有AJAX请求受到CORS的影响，在任何情况下仅知道客户端是浏览器是不足以满足要求的）。

- ADyson

---

谢谢。这让我感到困惑的是：一旦浏览器拥有了资源，黑客不可能从浏览器的内存中提取它吗？或者在它到达浏览器之前就可以拾取数据包吗？对我来说，这似乎很奇怪，我们发送的东西实际上不应该被接收方阅读。最后一个问题：浏览器和用户之间是否有某种隔离墙？也就是说，浏览器能否完全隐藏/隐瞒用户的数据？ - Magnus

一旦浏览器拥有了资源，黑客是否可能从浏览器的内存中提取它？我不太清楚，希望不会，但我猜如果黑客足够熟练，@Magnus可能会做到。 "在它到达浏览器之前捡起数据包？"是的，非常容易，但这不是重点-您也可以使用另一个工具（例如PostMan）向相同的URL发出HTTP请求，并以此方式获取数据，而无需遵循同源限制。 - ADyson

同源策略的目的不是防止访问资源，而是专门防止未经授权的跨域 AJAX 请求，以阻止不良网站上的恶意脚本造成损害。更详细的解释请参考 https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important。如果您想一般性地限制对 HTTP 资源的访问，则需要使用其他形式的安全性，例如身份验证或证书。 - ADyson

允许跨域内容的问题在于它可以利用浏览器会话中现有的凭据，从而绕过非浏览器HTTP客户端所面临的身份验证限制。以我刚刚发布的关于Facebook账户的链接为例 - 如果用户已经在会话中对Facebook进行了身份验证，并且另一个选项卡中的恶意脚本可以向Facebook发出跨域请求，则它可以使用浏览器中现有的身份验证cookie并在用户不知情的情况下执行任何操作，而浏览器外部的客户端则无法做到这一点。 - ADyson

我正在努力，给我几分钟：)) - Magnus