在安全方面，允许特定域的COR有意义吗？

Question

我们可以设置并允许跨源资源共享

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

但我想知道允许CORS为特定的领域有意义。

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

黑客可以将请求中的源头伪造为www.facebook.com

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

我说的对吗？？

Answer 1

浏览器是强制执行CORS限制的地方。浏览器知道脚本运行的真正起源。他们就是这样工作的。如果他们不这样做，网络上的安全性将为零。

因此，浏览器会根据他们所知道的生成XHR或getch（）请求的JavaScript代码的真实来源进行CORS检查，而不是根据Origin标头的值。

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

因此，即使您设法更改了浏览器通过网络发送的Origin标头，这对浏览器来说也无关紧要——它将忽略该值，并继续根据真正的原点进行检查。

更多细节

就CORS而言，服务器只需向任何请求它们的客户端发送带有访问-控制-允许-起源标头和其他CORS标头的文档。

如果您使用<代码> CURL<代码>或某事从服务器请求文档：服务器不检查<代码>原产地< /代码>头，如果请求源与“代码> >访问控制允许源代码< /代码>页眉，则拒绝发送文档。不管怎样，服务器都会发送响应。

就客户端而言，curl和非浏览器工具一开始就没有起源的概念，所以通常不会发送任何Origin头。您可以让curl发送一个-带有您想要的任何值-但是这毫无意义，因为服务器不在乎值是什么。

和curl等，不检查服务器发送的Access Control Allow Origin响应头的值，如果请求的Origin头与服务器响应中的Access Control Allow Origin头不匹配，则拒绝获取文档。他们刚拿到文件。

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

与curl等不同，如果请求文档的XHR或fetch（）调用来自服务器的Access Control Allow origin头中不允许的源，浏览器将不允许脚本获取文档。

同样，浏览器通过已经知道源代码是什么来确定源代码是什么，而不是基于origin请求头可能最终在请求中发送的值。