Understand the nature of CORS: what & why
Note: To get the best understanding, make sure to read MDN documentation of Same-origin policy and Cross-Origin Resource Sharing, as well as introduction to CSRF attack before or together with reading this article.
CORS is a headache for many us web developers and mysterious for some.
I get it, cross-origin resource sharing, it’s about stopping malicious websites from extracting data from my website; but if I can simply turn it off by installing a chrome plugin, how is it protective at all? Is it anything more than a trouble I must solve with “Access-Control-Allow-Origin” headers?
Although the mechanism is often referred to as “CORS error”, the restraints are actually introduced by the Same-Origin Policy (referred to as SOP in the following) and CORS is used to relax the restraints and intentionally allow some cross-origin data exchange.
The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin.
SOP works by disallowing cross-site content from being revealed.
So imagine website A is a malicious website but you’re tricked into browsing it, and website B is a site you visit often (so it still has valid authentication cookies) and provides some AJAX endpoint to get users’ sensitive information, like bank balance or current email.
Now website A starts sending HTTP request to website B to steal that information. If the developer of website B has yet to learn his lessons and didn’t add CSRF protection, because the request is associated with your session cookie, website A’s request will be fulfilled with your personal data.
And just when website A thinks he’s got it — SOP kicks in, and stops him or his evil code from reading anything returned by the website B. Instead the evil developer/program will get a “CORS error” telling him what is equal to “hey that website B didn’t put you down as Allow-Origin, so I’d better not show you what you requested. If you actually are authorised to know, ask website B to include your request in their CORS settings”.
It’s there in the response, but the browser won’t let him read it.
This is the most important thing when trying to understand SOP: it happens at the browser. And this is why:
- the same request will go through in Postman, but will throw a CORS error in the browser
- another server can request an endpoint just fine, but a request made by another website’s frontend will be blocked
It would be great if we can check and filter out requests made by cross-site websites on the server side, but that’s not secure: technically they are just all HTTP requests right(that can be manufactured)? Hence there’s no way for the server to know (for sure) whether this request is initiated by a cross-site web page. And it’s the browsers that will detect cross-site request, and stop the user or the program from reading data from it.
CORS, on the other hand, is a means to tell the browser, this website A is friendly, and I trust it. And the browser will pause its SOP mechanism on specified requests and allow the returned data to be read.
This is why those CORS disabling browser plugins are not likely to be used to compromise our security mechanism — why would a user install it? It will only put his own personal data (in the example above, data stored in website B) at risk. And an attacker using it just won’t get anything out of it.
As you can imagine, with CSRF protections widely adapted by websites, the problem that SOP/CORS is targeting is diminishing. But it certainly is important as a baseline security mechanism.
Also, here’s an article I found useful explaining how to fix CORS errors and what do CORS plugins do.
