Basics of Cross-origin Resource Sharing (CORS)

31 Mar 2018

Cross-Origin requests are request that are made by Server A for resources like images, scripts, CSS stylesheets, JSON, XML etc., that are available on Server B which is on different origin. Two servers are considered to be on different origin, If their URL differs either by domain name, protocol or port number.

Cross-Origin Resource Sharing (CORS) is a mechanism to enable sharing selected resources through cross-origin requests in a secure and authenticated way.

Why Cross-Origin request security required ?

Consider, If there are no restrictions and JavaScript from any domain is allowed to access resources on any other domain, then it can lead to

Illegal use/consumption of services provided by a website without their consent. i.e., a copycat website can be simply developed by using the legitimate website's public endpoints/service points - for example, you can create a front-end page for Google's Search page & attract users & gain revenue simply without any pain.

Hot linking resources from other websites. So high traffic puts load on other's server, while you earn money.

You can modify secure cookie or token of other website and do illegal transactions.

The illegal scraping or data access of the target site happens on the user's system.

So, to prevent such abuse,... cross domain/origin resources access were totally restricted. Later, JSONP based resource/data access method was introduced. But later, due to heavy increasing need for resource sharing across different origins, a more effective CORS mechanism was brought to handle cross site requests.

CORS security mechanism is a combination of implementation from server + user-agent. It is achieved using additional HTTP headers, that are set by the source server in the response to the requesting user-agent(browser), that lets the agent to gain permission to the resources.

All modern browsers support CORS, the security mechanism is as follows

When a cross-origin request is made by domain A to domain B, the browser first sends a preflight request using OPTIONS.

User agent/Web browser then validates the allowed origin name from the header.

If the origin name specified in the response header is same as domain A that requests the resources. The preflight requests succeeds.

Then the request from the script or page content from domain A is allowed to reach domain B. Or else denied by the browser.

The preflight response is cached for fixed duration specified in Access-Control-Max-Age header

CORS Headers:

1. Access-Control-Allow-Origin: <origin> | *

<origin> : Allows domain A to specify an origin name in the response header. Only the specified origin will be allowed to make request for that resource on domain A.* allows resource to be accessible for all origins. Without above header, browser will automatically block the Cross-Origin request if the origin in headers doesn't match.

2. Access-Control-Allow-Methods: POST, GET, OPTIONS

list of methods that are allowed on the requested resource.

3. Access-Control-Allow-Credentials: boolean

true - if the secure items like cookies and headers are allowed to be attached to subsequent Cross-origin resource requests to the origin specified in the CORS header.

4. Access-Control-Max-Age: <seconds>

specifies the number of seconds for which result from the preflight request can be cached. So that the subsequent request need not raise preflight OPTIONS request.