Demystifying CORS
frontendian.co
Demystifying CORS
1–10 of 50 posts
Re: Demystifying CORS
#2interesting article, although unfortunately it mentions but doesn't currently cover one of the more mis-understood parts of CORS, which is the Access-Control-Allow-Credentials part.
The fact that Access-Control-Allow-Origin: * doesn't work with Access-Control-Allow-Credentials, for example, is something I've seen sites get wrong quite a lot.
there's a good post which covers it https://mortoray.com/2014/04/09/allowing-unlimited-access-wi...
Re: Demystifying CORS
#3Nice article, though it doesn't cover CORS with NTLM/Kerberos auth (ie. .NET on windows).
To my mind this is the most baffling aspect here, as preflight requests shouldn't carry an auth token (according to the spec), however IIS is an all-or-nothing auth which will thus reject the preflight request, unless it is specifically handled.
Additionally, there are different ways to handle preflighting for owin and aspnetcore vs .NET framework (IIS hosting), and these methods also change depending on the technology - MVC, WebAPI, OData.
[edit] Hit return early:
MVC (pure) requests can be handled in the web.config to set custom headers. WebAPI uses annotations on the controllers. See https://stackoverflow.com/questions/29970793/enabling-cors-t...
OData follows a different path through, so the above won't work. You would need to modify Application_BeginRequest() See https://stackoverflow.com/questions/31459416/how-to-enable-c...
The above is all for .NET framework (IIS host). For OWIN you need to modify HttpListener as per https://stackoverflow.com/questions/42104716/owin-preflight-...
For aspnetcore the pipeline again changes: https://weblog.west-wind.com/posts/2016/Sep/26/ASPNET-Core-a...
Lastly, all of the above should be using xhr.withCredentials = true; on the client (javascript) side.
Note that this is not present for breeze-odata4 (I'm patching when I have time) but is present on Jaydata (though it's a shame Jaydata doesn't play nicely with webpack, only browserify).
Re: Demystifying CORS
#4This post never actually explains why any of this was needed. The closest it comes is this bit:
"If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin"
But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the old days you could simply proxy through a server if you needed to get around the same-origin policy, and I'm sure lots of people did.
I'd love if someone could explain why the whole CORS rigmarole was considered ncessary.
Re: Demystifying CORS
#5This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…
CORS was designed to mitigate e.g. the following attack:
* You are logged at with service X, which uses a Cookie to store your authentication code.
* Service X offers an endpoint to change your password, as well as an endpoint to retrieve your user account.
* You visit malicious website Y, which uses JS to send requests to the "change password" and "view profile" endpoints of service X (which without CORS would be accepted as the browser sends your authentication cookie with them), getting your profile information and changing your password, thereby taking over your account.
With CORS, for requests from third-party domains the browser first sends an "OPTION" pre-flight request to service X, which would then respond with a set of CORS headers from which the browser can determine if the given domain you're on (Y) is allowed to send requests to the service. If not, the request (e.g. GET, POST, PUT, DELETE) is not even sent. CORS therefore protects the user from malicious websites while still allowing requests from specific third-party domains (as there are legitimate use cases for sending API requests to a third-party website).
Note that CORS does not protect you from user-triggered requests (e.g. actively submitting an HTML form), for which you need CSRF tokens if you use cookies for authentication (which are sent automatically with each request).
Re: Demystifying CORS
#6This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…
Because those requests will contain authorization? Like cookies? Am I missing something?
Re: Demystifying CORS
#7This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…
My impression is that people wanted to make use of API's from third parties which would have been prevented by the same origin policies. CORS allowed them to relax that policy for the API's and services they wanted to use w/o totally removing the security against cross site scripting that the same origin policy provides. Having to proxy all requests through a server would have defeated the purpose of the new breed of paid APIs who's end goal seems to be to allow you to build a complex web site w/o having to wade into the details of maintaining the backed servers you would have traditionally needed and all the complexity that entails at scale.
Re: Demystifying CORS
#8This post never actually explains why any of this was needed. The closest it comes is this bit: "If [...] the same-origin policy for XMLHttpRequests relaxed, said services could now receive a deluge of DELETE, PUT, etc… requests from any origin" But why on earth is this a problem? And in any case those services always could receive requests from any origin, browsers aren't the only HTTP clients in the world. In the o…
Well, there are a number of reasons, but let me give you one of the more important ones:
If a browser were allowed to make cross-origin requests without restrictions, any site could take advantage of a user’s active session on any other site to perform unapproved actions on that user’s behalf. Without CORS, for instance, if you came to my site with an active Facebook session, I could get information about your account (by making cross-origin requests to Facebook) that I wouldn’t otherwise have access to. Or, if I were feeling a bit more nefarious, I could change information — possibly your password and gain control of your account.
The possibIlities for bad actors to do these types of things is also part of the reason CORS requests don’t include most headers by default, and you have to be very explicit about which headers to expose.
Re: Demystifying CORS
#9Alex Hopperman talks about XMLHttpRequest starting as an initiative to port exchange/outlook email to a browser: http://www.alexhopmann.com/xmlhttp.htm
XMLHTTP actually began its life out of the Exchange 2000 team. I had joined Microsoft in November 1996 and moved to Redmond in the spring of 1997 working initially on some Internet Standards stuff as related to the future of Outlook […] I don’t recall exactly when we started working on Outlook Web Access in Exchange 2000. I think it was about a year after I joined the team, probably sometime in late 1998 […] we were already a milestone or two into the Exchange 2000 (or “Platinum”) project and had been carefully ignoring the issue of OWA [Outlook Web Access] mostly because the old version was such a hack. […] The basic premise of Outlook Web Access was that you could walk up to any computer that had the browser on it and just get to your email […] The [XMLHttpRequest] beta shipped and the OWA team was able to start running forward using the beta IE5,
Re: Demystifying CORS
#10What I find perplexing is that for this and every other web technology, there doesn't seem to be a central comprehensive resource that explains it all in great detail.
It's like we have to pick things up as we go along, from tidbits and articles here and there, not of it complete or comprehensive, and often there'll be little mistakes or misleading bits.