Crash course about CORS

This article is dedicated to my dear brother Omer Cohen who's always pushing towards being a better developer.

Access to XMLHttpRequest at 'https://localhost:3000' from origin 'https://localhost:8000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource

Does the above error look familiar to you?

If you are a full-stack web developer, you most probably already tackled this error. Experienced full-stack developers will realize they forgot to add the CORS header as a middleware, newbies will have to google for it.

But what is this CORS all about? Why do we need it? And how understanding it will make us better full-stack developers. All about it, and more in the next article. Stay tuned!

What is this CORS all about

CORS stands for Cross-Origin Resource Sharing. In simple words, it means, that when our browser gets a resource(Javascript, HTML, CSS) from domain A, we have some rules about sharing it with domain B.

Actually, CORS is an extension of the SOP policy, so in order to understand CORS, we have to get familiar with the Same-Origin-Policy.

SOP is a web browser security mechanism that is supposed to protect your private data from malicious websites.

When a browser sends an HTTP request to a server, any cookies, including authentication session cookies, relevant to the other domain are also sent as part of the request. Now imagine yourself what will happen if this sensitive data will be sent to every website we visit? This is where SOP comes into action. It checks if the sensitive data we have such as cookies "belongs" to the current website we are visiting and only then allowing access to these pieces of data.

This is also true for DOM access (by JavaScript). If a JavaScript file (from another origin) is trying to access your DOM elements from a domain that is not the origin of the HTML file, it will be blocked by your browser, according to the SOP.

Let us say you are somehow tricked into visiting www.your-bank.bad-site.com. On that bad site, there is an iframe that loads www.your-bank.com, where you proceed to login legitimately. After logging in, a simple JavaScript call on the bad site could be used to access the DOM elements of www.your-bank.com loaded in the iframe, such as your account balance. Now imagine what they can do...

frames.bank_frame.document.getElementById("balance").value

What this does is access the iframe element (named bank_frame), then within that iframe's DOM, it accesses the HTML element named balance and gets its value. This could of course even be extended to forging browser calls to send your money elsewhere! Without Same-origin Policy, these kinds of cross-site requests could be executed without your consent or knowledge.

However, it is important to know, that the SOP also looks for the context of our files running on our browser. If we have a JS file that was loaded from another origin (through a CDN) the browser will allow it to run on our browser because it was loaded by that HTML file. It has the same context as our HTML file.

?By the way, there are strict rules about what is considered "same-origin". One of them for example is having the same port. So if we get an HTML file from https://www.example.com:8080, it will not be shared with https://www.example.com:8081. This sounds too strict? This is where CORS comes into action.

Flexibility in a world of sharing

So we learned about how it is restricted for our browser to share resources from different origins. But what if we do want to share a resource? Is there a safe way to bypass the strict mechanism of the SOP?

Consider the following most common example: We enter a website and get a resource from it - Some HTML, CSS, and JS. Now we have to make another request to a different origin to get our data from a REST API. According to the SOP, this not allowed! The request will be sent, but our browser will block the response.

CORS configuration is mainly handled server-side. We basically have to set some headers that will be sent with the response from the server. If the response contains the correct headers, then the response will not be blocked by the browser. I just want to emphasize that CORS and SOP policy are browser things.

For example, if we send a request from our browser to a REST API, and for some reason, the server is not configured to send us back the correct headers and thus making our browser block the response, there is a way to bypass it!

The solution for that will be to set up a proxy that will act as an "agent" between our browser and that API. When the proxy sends the request to that server, it will of course not block the response from that server. We can then set up the proxy with the correct headers to send that response back to our browser.

Conclusion

In this article, we learned about the SOP and CORS. They are both meant to serve as security and privacy mechanisms for users around the web. It keeps the data that we receive in our browser (HTML and so on) away from malicious attackers.

It is important to remember that CORS is a security mechanism for the browser user, but we set it up server-side. If the response from the server has the correct headers then our browser will not block it.

I did not elaborate on how to configure those headers because this article was about understanding how CORS generally works and why we need it. You can use these resources if you want to learn about how to configure CORS headers:

• CORS on MDN.
• A good article from medium.
• A complete guide from Oauth.