在各自的安全性中，允许特定域的CORS是否有意义？

Question

我们可以设置并允许

的跨源资源共享

所有域，特定域和不允许任何域

但我想知道特定域的 CORS 是否有意义。

如果黑客知道服务器允许的域名。 （例如www.facebook.com）

黑客可以伪造请求中的原始标题 www.facebook.com

因此，从安全的角度来看。我认为只有允许所有域和不允许任何域才有意义。因为很容易伪造请求者的 origin

我是对的吗？

Answer 1

浏览器是强制执行CORS限制的地方。浏览器知道脚本运行的真实来源。这就是它们的工作方式。如果他们不这样做，那么网络上就没有安全保障。

因此，浏览器会针对他们所知道的正在制作XHR或fetch()请求的JavaScript代码的真正来源进行CORS检查，而不是Origin标头的值。

浏览器是设置 Origin请求标头的内容，并通过网络发送。浏览器根据他们所知道的真实来源设置Origin值，而不是为了他们自己的使用 - 因为他们已经知道原点是什么，并且该值是他们在内部使用的值。

因此，即使您设法更改浏览器通过网络发送的Origin标头，这对浏览器无关紧要 - 它将忽略该值并继续检查真实来源。

更多详情

就CORS而言，服务器只是向任何请求它们的客户端发送带有Access-Control-Allow-Origin标头和其他CORS标头的文档。

考虑您是否使用curl或其他东西从服务器请求文档：服务器不检查Origin标头，如果请求来源与请求来源不匹配则拒绝发送文档Access-Control-Allow-Origin标题。无论如何，服务器都会发送响应。

就客户而言，curl和非浏览器工具没有开头的概念，因此通常不会发送任何Origin标头。你可以让curl发送一个你想要的任何值 - 但它没有意义，因为服务器不关心它的价值。

curl等，不检查服务器发送的Access-Control-Allow-Origin响应头的值，如果请求的Origin标头没有，则拒绝获取文档匹配服务器响应中的Access-Control-Allow-Origin标头。他们只是得到了文件。

但浏览器不同。浏览器引擎实际上是唯一具有开头概念的客户端，并且知道运行Web应用程序的JavaScript的实际来源。

与curl等不同，如果请求XHR或fetch()的来自服务器Access-Control-Allow-Origin标题中不允许的来源，浏览器不会让您的脚本获取文档

同样，浏览器通过已经知道原点是什么来确定原点的方式，而不是基于任何Origin请求标头的值可能最终会被发送到请求。