What is CORS and why do we need it ?

To understand what CORS is and why do we need it, first we need to understand what Same-Origin Policy (SOP) is.

The SOP was developed as a security mechanism for browsers to fight malicious attacks. It checks if the origins of the web application which is making the request and the server match.

Origin = protocol + host + port number

How does CORS work?

The key players in a CORS request are the client, the browser, and the server. The client wants some piece of data from the server. The browser acts as the trusted intermediary to verify that the client can access the data from the server.

The browser and the server talk to each other through HTTP headers. HTTP headers carry the details of the CORS request, including whether the CORS request is allowed.

CORS is built around many headers, but the two most important are:

• The Origin request header
• The Access-Control-Allow-Origin response header

The browser is solely responsible for setting the Origin header to indicate where a request is coming from. Origin helps define whether a request is same-origin or cross-origin. A request is same-origin when the client origin and the server origin are the same (same-origin requests are allowed without any restrictions).

Otherwise, the request is a cross-origin request (in this case browser uses CORS to determine how to handle the request).

The server responds with the Access-Control-Allow-Origin header if the request is valid. The value of the Access-Control-Allow-Origin header can be either a wildcard (*) or an origin value. The wildcard value means that clients from any origin can access the resource, while the origin value only gives access to a specific client.

CORS puts servers firmly in charge of who can make requests, and what type of requests are allowed. A server has the option to open its API to all clients, to a group of clients or prevent access to all clients.

What about Preflight requests?

Access-Control-Allow-Origin header is required on all valid CORS responses, but there are certain types of requests (such as DELETE or PUT) for which this header alone is not enough.

For these types of requests, the browser needs to ask for server’s permission before making the actual request, using a preflight request (OPTIONS request).

A preflight request contains information like which HTTP method is used, as well as if any custom HTTP headers are present. The preflight gives the server a chance to examine what the actual request will look like before it is made.

The server receiving the preflight request must respond with CORS headers indicating whether the actual request should be permitted.

Besides Access-Control-Allow-Origin header the server should respond with the following CORS headers:

Access-Control-Allow-Methods - specifies the allowed HTTP methods

Access-Control-Allow-Headers - specifies the allowed headers

If the response to the preflight request is successful, the browser will go ahead and send the actual request to the server. If the preflight request fails or the server's response does not allow the actual request, the browser will block the subsequent request, and an error will be thrown.

In conclusion, CORS headers allow web servers to control which domains can access their resources, ensuring a secure and controlled environment for cross-origin requests. It helps prevent unauthorized access to sensitive data and reduces the risk of data breaches. It is also a straightforward way to overcome browsers default Same Origin Policy Restrictions.