In spy movies, security operatives have a coded way of transmitting information amongst themselves. Since they are mostly transmitting information that can be used against them if it falls in the hands of their enemies, they have to make sure that those who are receiving the information are trusted parties. The same applies to those who are sending the said information. When the sender and receiver are trusted, the credibility and security of the information can be guaranteed. A replica of this scenario happens in the communication between browsers and web servers, and it is called the same-origin policy. According to MDN:
What is CORS?
In a real-life case, when security operatives give a rule that communication should only happen amongst its operatives as a means of security, that’s similar to the same-origin policy. Yet, there might be cases where they will need to interact with the outside world. Or with operatives of other security outfits, for that to happen, they can implement another security measure to verify those operatives. This verification can come in different ways, depending on the operatives involved. In the case of communication on the Internet, CORS is the mechanism that makes it possible for browsers use to access resources that they originally will not be able to because the resource is of a different origin. I have talked about origin more than once, and you’re probably wondering what that means. An origin is defined by the protocol, domain, and port of the URL. When you have your API at an origin like https://api.geekflare.com:3001 and your frontend at https://geekflare.com, the origins are said to be different. In this situation, you’ll need CORS to be able to access resources on both ends. When requests are made to a server, the browsers (client) and servers send requests and response, HTTP headers are included. Amongst these headers, additional headers are included to prevent the browser from blocking the communication. Why will the browser block the communication? Its browser security features. It will do so if the request is coming from an origin different from that of the client. The additional headers included as a result of CORS is a way of telling the client that it can make use of the response that it received.
CORS Headers
One of the secure headers which can be either response or request header.
Response Headers
These are the headers that the server sends back in its response.
Access-Control-Allow-Origin:
Here is an example of what the response will look like
Request Headers
Here are the headers that a client’s request should contain in order to make use of the CORS mechanism.
Origin:
Here is an example of what a request will look like
Preflight Requests
After mentioning preflight requests here and there, what could it possibly mean? Preflight requests happen when the client has to send a preflight request before the main request. The preflight request is more of a probe to determine if the server supports the main request that’s about to be made. When positive confirmation is obtained, the main request is then sent. When a request is not a preflight request, it is called a simple request.
Implementing CORS
You mostly will want to set up things at the backend of your application. The implementation depends on the framework you are using. For this tutorial, we will look at how to do it in NodeJS and Rails.
Rails
I recommend you make use of the rack-cors gem. Then you’ll need to add this to your config/application.rb file.
NodeJS
In Node.js, this will look like this. In the code snippet, we are setting up the origin, methods, headers, and credentials that should be allowed to access the resources available on our server. You may also checkout Sqreen who provides a security headers module to be integrated with Ruby, PHP, Python, Java, Go, Node.JS applications. And to implement in Apache or Nginx, refer to this guide. Conclusion CORS relaxes the policy so that your browser can access the resources you want it to. Understanding what it is, why it’s essential, and how to set it up will help in figuring out the issues you might face as you build your web applications.