Escolar Documentos
Profissional Documentos
Cultura Documentos
Contents
Simple example
When a CORS-compatible browser attempts to make a cross-origin request:
1. The browser sends the request with an Origin HTTP header. The value of this header is
the domain that served the parent page. When a page from http://www.foo.com attempts to
access a user's data in bar.com, the following request header would be sent to bar.com:
Origin: http://www.foo.com
An error page if the server does not allow the cross-origin request
An Access-Control-Allow-Origin (ACAO) header with a wildcard that
allows all domains:
Access-Control-Allow-Origin: *
This is generally not appropriate when using the same-origin security policy. The only case where
this is appropriate when using the same-origin policy is 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. For example, this policy is appropriate for freely-available web fonts on public hosting services
like Google Fonts.
On the other hand, this pattern is 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 HTTP
authentication, client-side SSL certificates, nor does it allow cookies to be sent.[4]
Note that in the CORS architecture, the ACAO header is being set by the external web service
(bar.com), not the original web application server (foo.com). CORS allows the external web service
to authorise the web application to use its services and does not control external services accessed
by the web application. For the latter, Content Security Policy should be used (connect-src
directive).
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.
OPTIONS /
Host: bar.com
Origin: http://foo.com
If bar.com is willing to accept the action, it may respond with the following headers:
Access-Control-Allow-Origin: http://foo.com
Access-Control-Allow-Methods: PUT, DELETE
Headers
The HTTP headers that relate to CORS are:
Request headers
Origin
Access-Control-Request-Method
Access-Control-Request-Headers
Response headers
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Browser support
CORS is supported by all browsers based on the following layout engines:
Gecko 1.9.1 (Firefox 3.5,[5] SeaMonkey 2.0,[6] Camino 2.1[7]) and above.
WebKit (Initial revision uncertain, Safari 4 and above,[1] Google Chrome 3 and above,
possibly earlier)[8]
MSHTML/Trident 6.0 (Internet Explorer 10) has native support.[9] MSHTML/Trident 4.0 &
5.0 (Internet Explorer 8 & 9) provide partial support via the XDomainRequest object.[1]
Presto-based browsers (Opera) implement CORS as of Opera 12.00[10] and Opera Mobile
12, but not Opera Mini.[11]
The following browsers are also noteworthy in their lack of CORS support:
Camino does not implement CORS in the 2.0.x release series because these versions are
based on Gecko 1.9.0.[12]
As of version 0.10.2, Arora exposes WebKit's CORS-related APIs, but attempted crossorigin requests will fail.[13]
History
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[14] 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.[15] 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.
CORS vs JSONP
CORS can be used as a modern alternative to the JSONP pattern. While JSONP supports only the
GET request method, CORS also supports other types of HTTP requests. Using CORS enables a
web programmer to use regular XMLHttpRequest, which supports better error handling than
JSONP. On the other hand, JSONP works on legacy browsers which predate CORS support. CORS
is supported by most modern web browsers. Also, while JSONP can cause cross-site scripting
(XSS) issues where the external site is compromised, CORS allows websites to manually parse
responses to ensure security.[2][16]