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

  1. When a cross-origin request is made by domain A to domain B, the browser first sends a preflight request using OPTIONS.
  2. Domain B responds to this request with CORS HTTP headers - Access-Control-Allow-Origin.
  3. User agent/Web browser then validates the allowed origin name from the header.
  4. If the origin name specified in the response header is same as domain A that requests the resources. The preflight requests succeeds.
  5. Then the request from the script or page content from domain A is allowed to reach domain B. Or else denied by the browser.
  6. 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.

For a more detailed list of all CORS headers, refer https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Related Posts