Cross-origin resource sharing


Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.
A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain "cross-domain" requests, notably Ajax requests, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests.
The specification for CORS is included as part of the WHATWG's Fetch Living Standard. This specification describes how CORS is currently implemented in browsers. An earlier specification was published as a W3C Recommendation

How CORS works

The CORS standard describes new HTTP headers which provide browsers with a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser's responsibility to support these headers and honor the restrictions they impose.
For Ajax and HTTP request methods that can modify data, the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" should be sent with requests.

Simple example

Suppose a user visits http://www.example.com and the page attempts a cross-origin request to fetch the user's data from http://service.example.com. A CORS-compatible browser will attempt to make a cross-origin request to service.example.com as follows.
  1. The browser sends the GET request with an extra Origin HTTP header to service.example.com containing the domain that served the parent page:
    Origin: http://www.example.com
  2. The server at service.example.com may respond with:
  3. * The requested data along with an Access-Control-Allow-Origin header in its response indicating the requests from the origin are allowed. For example in this case it should be: 
    Access-Control-Allow-Origin: http://www.example.com
  4. * The requested data along with an Access-Control-Allow-Origin header with a wildcard indicating that the requests from all domains are allowed: 
    Access-Control-Allow-Origin: *
  5. * An error page if the server does not allow a cross-origin request
A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. A freely-available web font on a public hosting service like Google Fonts is an example.
A wildcard same-origin policy is also widely and appropriately used in the object-capability model, where pages have unguessable URLs and are meant to be accessible to anyone who knows the secret.
The value of "*" is special in that it does not allow requests to supply credentials, meaning it does not allow HTTP authentication, client-side SSL certificates, or cookies to be sent in the cross-domain request.
Note that in the CORS architecture, the Access-Control-Allow-Origin header is being set by the external web service, not the original web application server. Here, service.example.com uses CORS to permit the browser to authorize www.example.com to make requests to service.example.com.

Preflight example

When performing certain types of cross-domain Ajax requests, modern browsers that support CORS will insert an extra "preflight" request to determine whether they have permission to perform the action. Cross-origin requests are preflighted this way because they may have implications to user data.

OPTIONS /
Host: service.example.com
Origin: http://www.example.com

If service.example.com is willing to accept the action, it may respond with the following headers:

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: PUT, DELETE

The browser will then make the original request. If service.example.com does not accept cross-site requests from this origin then it will respond with error to the OPTIONS request and the browser will not make the original request.

Headers

The HTTP headers that relate to CORS are:

Request Headers

CORS is supported by all browsers based on the following layout engines:
Cross-origin support was originally proposed by Matt Oshry, Brad Porter, and Michael Bodell of Tellme Networks in March 2004 for inclusion in VoiceXML 2.1 to allow safe cross-origin data requests by VoiceXML browsers. The mechanism was deemed general in nature and not specific to VoiceXML and was subsequently separated into an implementation NOTE. The WebApps Working Group of the W3C with participation from the major browser vendors began to formalize the NOTE into a W3C Working Draft on track toward formal W3C Recommendation status.
In May 2006 the first W3C Working Draft was submitted. In March 2009 the draft was renamed to "Cross-Origin Resource Sharing" and in January 2014 it was accepted as a W3C Recommendation.

CORS vs JSONP

CORS can be used as a modern alternative to the JSONP pattern. The benefits of CORS are:
The main advantage of JSONP was its ability to work on legacy browsers which predate CORS support. CORS is now supported by most modern web browsers.