John Kemp, 1st June 2010
(updated from email http://www.w3.org/mid/A0B0892B-1902-4A5B-84B7-9231B56A7540%2540jkemp.net including further explanation spurred by email comments from Mark Miller)
Current Web security depends on the Web browser "same origin policy", which says that HTTP requests made from within a document retrieved from some origin (scheme, host + port) must only be allowed to the same domain.
The same-origin policy evolved in response to the development of cookies in Netscape Navigator 2.0. Cookies are stored in the browser per-domain, and are sent in all requests to the domain which stored them.
Without a check for same-origin, a document retrieved from site A can contain an AJAX request to site B, and site B's cookies will be sent.
This would allow a malicious HTTP request initiated by some origin going to a different origin - allowing "cross-site request forgery" and other cross-origin attacks. Such a malicious request is made possible by the inability of a client to tell that it should not send local shared client state (such as cookies) to a particular origin when a malicious request is initiated, and the lack of a user prompt in many of these scenarios (making it impossible for a user to even see whether something might be going wrong).
The rules for the same-origin policy are not enforced reliably (not, for example, in the 'src' attribute of a <script> tag - see [CrockScript]), which has led to the use of techniques which allow cross-domain requests, such as the widespread use of dynamic script tags and use of "iframes" to allow multiple documents from several origins to exist within the same containing document, or JSONP -- all of which may open further security vulnerabilities based on the origin-based algorithms.
Several approaches have been proposed to allow browsers to safely make requests to multiple server domains.
Historically, Adobe's Flash plugin has supported cross-domain requests by allowing Web sites to publish a file [AdobeCrossDomain] containing a list of origins which are allowed to make requests of that site. The restrictions are maintained by the Flash plugin checking this file.
The Cross Origin Resource Sharing (CORS) specification [CORS] allows an origin to explicitly opt-in to a model for sharing access to its resources with a set of other, named, origins - in other words, to intentionally allow cross-origin requests from a named subset of origins. That model may then be used by other specifications in order to expose cross-origin requests via the specified APIs.
One API specified which utilizes CORS is specified in XMLHttpRequest2 [XHR2].
Microsoft Internet Explorer 8 introduced the XDomainRequest [XDR] object, which similarly allows cross-domain requests, employing the Access-Control-Allow-Origin HTTP header related to CORS, to describe the list of allowed sites.
There is a section of the Web community which claims that the origin-based access-control model, regardless of the security measures implemented in the CORS/XHR2 algorithms, is inherently vulnerable to cross-origin security issues because of its reliance on an identity-based, "ambient authority" (cookies) model where, because of the presence of intermediaries, it is impossible with this model to reliably "authenticate" the origin of a request, yet user credentials (such as cookies) are sent automatically to a server.
An alternative model, which does not rely on attestations of identity, is proposed in the Uniform Messaging Policy specification. That document proposes an alternative to both CORS (ie. it proposes that an origin server may "opt-in" to requests from all domains, not a named subset controlled by the client) and XHR2 (UMP proposes a new XHR API that applies the same policy to same-origin requests as to cross-origin requests). UMP does not propose a specific access-control mechanism, but expects that parties involved in a web application will authenticate each other in ways other than by using origin-based access control, such as by the sharing of authorization tokens between the parties. One potential multi-party mechanism is described in [CORSChallenge].
It has been proposed that UMP could form a subset of the CORS specification (using the 'credentials' flag of CORS).
Allows a server to opt-out of user-agent same-origin protection for a named set of origins via the Access-Control-Allow-Origin HTTP header
Proposes that all HTTP requests send an Origin HTTP header (as a replacement for HTTP's Referer header) to indicate the "identity" of the requesting Web site.
Provides a server processing model [CORS-Server] for informing a requester of which cross-origin features it supports (including a list of origins, but also which HTTP headers and methods it supports on per-url basis)
Provides an algorithm for user-agents to follow [CORS-UA] to correctly send the Origin HTTP header and distinguish between origins.
Offers a means of ensuring that a request with side-effects (such as HTTP PUT, DELETE methods) is acceptable to a server without sending the actual request, via a "pre-flight request".
Allows a server to opt-out of user-agent same-origin protection for ALL requests.
Specifies a uniform request [UReq] - an HTTP request which is free of indications of origin, and other credential mechanisms such as cookies, with the purpose of removing the possibility for a cross-origin attack.
Specifies a uniform response [UResp] - an HTTP response which contains an Access-Control-Allow-Origin header with a value of "*".
Leaves access-control out of scope within the specification, but suggests that "permission tokens" be used to limit access on a per-request, per-resource basis (ie. independent of the requesting origin, or user state)
Same-origin policy was a response to security threats regarding user-credential cookies, belonging to an unsuspecting user, being sent by a malicious Web site to an unsuspecting Web site, and more generally, to the sending of requests with unpleasant side-effects to unsuspecting Web sites.
Same-origin policy requires relatively complex checks by the user-agent when determining when a request, and cookies, should be sent
Same-origin policy is unreliable and implemented inconsistently. Cross-origin requests are already possible today, using various techniques (such as iframes, JSONP et al).
typically not in the common two-site case, but in more complex multi-party scenarios such as [PrinterExample]. Such examples might be protected by the "Don't be a deputy" (DBAD) discipline, proposed in [DBAD], slide 21. Use of DBAD appears to to rely upon parsing the path component of URIs (see [CORS-DBAD] @@TODO: need better link) It is also, even without cookies involved, still possible for one site to spoof Origin (or cause the Origin header value to be meaningless).
UMP allows the complete prevention of such attacks, and relies upon relatively well-understood and deployed mechanisms (for example CSRF tokens, as described in [BMJ]) for authenticating cross-site requests in order to do so.
UMP "level 1" and CORS differ in the use-cases they support, mostly because CORS supports a "pre-flight" request (using the HTTP OPTIONS method to determine which methods are supported for an origin, prior to sending the actual request) whereas UMP supports only those HTTP methods allowed in an HTML form [UMPReqParams]. A future UMP "level 2" specification may also support the pre-flight request, and other HTTP methods.