An Introduction to CORS
CORS stands for Cross Origin Resource Sharing. In January 2014, the W3C WebApps Working Group accepted Cross Origin Resource Sharing (CORS) to allow browsers securely load resources (such as web fonts, images, etc) from servers in another domain other than their own domain. This is achieved by putting a Security Policy in place.
Why is Security Policy Necessary for Browsers’ Requests?
Security policy is necessary to protect browsers’ request from malicious sites, that can exploit information (cookies) stored by the browser to make unauthorized requests to other domains.
For instant, when we enter some of our details to login to a website without a security policy in place, malicious sites can make use of these details to gain unauthorized access to our account.
One of the dangers of unsecured request is that, our request is not guaranteed to be safely received by the server and also the response sent by the server.
Same Origin Policy (SOP)
In an attempt to secure our browsers’ requests and servers’ responses, Same-Origin Policy restricts browsers from making requests to servers outside of its own domain. For example, a document hosted on Server 1 can only be accessed by the browser in the same origin as the server. Likewise, document hosted on Server 2 can only be accessed by browser in the same origin.
What is an Origin? An origin is made up of the following three parts: the protocol, host, and port number.
User 1 will have access to the resources on the Server, because they are on the same domain. User 2 will have its requests rejected since it’s not on the same domain as the Server. Same-Origin Policy sees it as Cross-Site Request Forgery.
Cross-Site Request Forgery (XSRF) is the type of security and vulnerability issues addressed by Same-Origin Security Policy.
SOP solves the problem at hand, but we still need to access resources from different servers in order build a scalable application. Not letting go the security of our application and the reliability of resources being accessed. This is where CORS comes in.
What, exactly, is CORS?
CORS is a mechanism that allows a browser to load resources (such as web fonts, images, etc) from servers in another domain other than their parent domain. That is, unlike Same Origin Policy, CORS allows us to securely access resources from other servers across the internet by using additional HTTP headers to inform our browser to let our application have access to resources on another domain (server).
Most of the browsers support CORS for the client side. But for servers, CORS allows us to specify who can access the resources and how it could be accessed.
Browsers make Cross Origin requests — using HTTP request header — to the server on another domain (Origin). Most servers accept requests to read only their assets (resources), that is, GET request.
How does CORS handle request from browser to server and vice versa?
CORS pass an HTTP header back and forth between a client (browser) — that want to access resources hosted on a different server — and the server. The headers are used to describe requests (from the browser/client) and responses (from the server).
An HTTP header is a piece of information associated with a request or a response.
CORS standard uses several HTTP headers. These are a few of them:
i. Access-Control-Allow-Origin.
ii. Access-Control-Allow-Headers.
iii. Access-Control-Allow-Methods.
iv. Access-Control-Request-Headers.
v. Access-Control-Request-Methods.
The “Access-Control-Allow-Origin” is important to the security of resource sharing across different Origin.
For example: If a client on domain ’’http://belt.io“ wants to access resources on a server with the domain name ”http://shirt.me”.
The server must specify “Access-control-allow-origin: “http://belt.io” for the client to be able to access the resources on the server.
Most servers use “Access-control-allow-origin: *” to allow browsers from different domain across the internet to access its resources.
Simple Requests
Requests that cannot harm the server’s data, such as HTTP Request methods like GET, POST and HEAD are called Simple Requests.
Preflight Requests
Requests that can harm the server’s data are “preflighted”. Preflight requests first send an HTTP request by the OPTIONS method to the server; it wants to access its resources, in order to determine if the actual request is safe to send.
Generally, requests can be “preflighted” on several conditions, one of which is, if a request uses any of the following methods;
· PATCH,
· OPTIONS,
· DELETE,
· CONNECT,
· PUT and
· TRACE.
Request with any of the methods above can modify the data on the server. The purpose of the preflight request is to determine whether the original request is safe (imagine a DELETE request). That is why the request is “preflighted” with an OPTION method.
The server responds to the preflight request and specifies if the original request is safe or not. If the original request is safe, it is allowed. If not, the server blocks the request.
Last take
Making requests to external sites without CORS can be risky. CORS allows us to build scalable applications by accessing resources from different servers. Like making API calls, load Google fonts, load images from another server, and others without jeopardizing the security and reliability of our application.
There are several resource sharing mechanisms for web technologies, but their concepts will always remain the same. Understanding how CORS works and how to implement it can be a game-changer in building a secure application.
For deeper understanding on how to implement CORS, CORS error messages, identifying the issues, etc., for different Backend languages, check out my article on “Intermediate Guide to CORS”.
