With appropriate security, does it make sense to enable CORS for specific domains?

We can establish and allow sharing of source resources for

All Domains , Specific Domains and Do Not Allow Any Domains

But I am interested in allowing CORS for specific domains .


If the hacker knows the domains that the server allows. (e.g. www.facebook.com )

A hacker can fake a source header in a request like www.facebook.com


Thus, in a safety perspective. I think it only makes sense to Allow all domains and Do not allow any domains . Since it is very easy to fake the origin of the requester

I'm right?

+2
cors
Nov 28 '16 at 1:18
source share
1 answer

Browsers with CORS restrictions. And the browser knows the real origin of the script. This is how they work. If they did not, there would be zero security on the Internet.

In this way, CORS browsers verify that they know the real origin of JavaScript code making an XHR or fetch() request, and not the value of the Origin header.

And browsers are what sets the Origin request header and sends it over the network to get started. Browsers set the Origin value based on what they know is a real source, not for their own use, because they already know what the origin is, and that value is what they use internally.

Thus, even if you manage to change the Origin header, the browser will send over the network, which does not matter for the browser, it will ignore this value and continue checking for real origin.




More details

As for CORS, servers simply send back documents with the Access-Control-Allow-Origin header and other CORS headers to any client that requests them.

Consider whether you use curl or something to request a document from the server: the server does not check the Origin header and refuses to send the document if the requesting origin does not match the Access-Control-Allow-Origin header. The server sends the response independently.

And as for clients, curl and non-browser tools do not have a clue to the beginning of the beginning and, as a rule, usually do not send the Origin header to start. You can make curl send one - with whatever value you want, but it is pointless because the servers do not care about what that value is.

And curl , etc., do not check the value of the Access-Control-Allow-Origin response header sent by the server, and refuse to receive the document if the Origin header does not match the Access-Control-Allow-Origin header in the server response, They just get the document .

But browsers are different. Browser engines are actually the only clients who have a concept of origin, and they know in what actual origin the JavaScript web application works.

And unlike curl , etc., browsers will not allow your script to get a document if an XHR or fetch() call requesting it comes from a source not allowed in the Access-Control-Allow-Origin server header.

And again, how browsers determine what happened, already knowing what the source is, not based on the value of any Origin the request header, may be sent in the request.

+2
Nov 28 '16 at 3:05
source share



All Articles