Access Control for Cross-Site Requests

Abstract

This document defines a mechanism to enable client-side cross-site requests. Specifications that want to enable cross-site requests in an API they define can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-site from http://example.org.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 12 September 2008 Working Draft of the "Access Control for Cross-Site Requests" document. It is expected that this document will progress along the W3C Recommendation track. This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain.

Please send comments to the WebApps Working Group's public mailing list public-webapps@w3.org with [access-control] at the start of the subject line. Archives of this list are available. See also W3C mailing list and archive usage guidelines.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

• 1. Introduction
• 2. Conformance Criteria
  • 2.1 Terminology
• 3. Security Considerations
• 4. Syntax
  • 4.1 Access-Control-Allow-Origin HTTP Response Header
  • 4.2 Access-Control-Max-Age HTTP Response Header
  • 4.3 Access-Control-Allow-Credentials HTTP Response Header
  • 4.4 Access-Control-Allow-Methods HTTP Response Header
  • 4.5 Access-Control-Allow-Headers HTTP Response Header
  • 4.6 Origin HTTP Request Header
  • 4.7 Access-Control-Request-Method HTTP Request Header
  • 4.8 Access-Control-Request-Headers HTTP Request Header
• 5. Processing Model
  • 5.1 Cross-Site Access Request
    • 5.1.1 Cross-Site Access source origin
    • 5.1.2 Cross-Site Access Request Header Lists
    • 5.1.3 Simple Cross-Site Access Request
    • 5.1.4 Cross-Site Access Request with Preflight
    • 5.1.5 Generic Cross-Site Access Request Algorithms
  • 5.2 Access Control Check
• Requirements
• Use Cases
• Design Decision FAQ
• References
• Acknowledgments

1. Introduction

Web application technologies commonly apply same origin restrictions to network requests. These restrictions prevent a Web application running from one origin from obtaining data retrieved from another origin, and also limit the amount of unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application's origin.

In Web application technologies that follow this pattern, network requests typically use ambient authentication and session management information, including HTTP authentication and cookie information.

This specification extends this model in several ways:

• Web applications are enabled to annotate the data that is returned in response to an HTTP request with a set of origins that should be permitted to read that information by way of the user's Web browser.

  The policy expressed through this set of origins is enforced on the client.

• Web browsers are enabled to discover whether a target resource is prepared to accept cross-site HTTP requests using non-GET methods from a set of origins.

  The policy expressed through this set of origins is enforced on the client.

• Server side applications are enabled to discover that an HTTP request was deemed a cross-site request by the client Web browser, through the Origin HTTP header.

  This extension enables server side applications to enforce limitations on the cross-site requests that they are willing to service.

This specification is a building block for other specifications, so-called hosting specifications, which will define the precise model by which this specification is used. Among others, such specifications are likely to include XMLHttpRequest Level 2, XBL 2.0, and HTML 5 (for its server-sent events feature).

The design of this specification introduces is based on requirements and use cases, both included as appendix. A FAQ describing the design decisions is also available.

Access-Control-Allow-Origin: http://hello-world.example

Hello World!

new client = new XMLHttpRequest();
client.open("GET", "http://example.com/hello")
client.onreadystatechange = function() { /* do something */ }
client.send()

Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800

Access-Control-Allow-Origin: http://hello-world.example

function deleteItem(itemId, updateUI) {
  var client = new XMLHttpRequest()
  client.open("DELETE", "http://calendar.example/app")
  client.onload = updateUI
  client.onerror = updateUI
  client.onabort = updateUI
  client.send("id=" + itemId)
}

2. Conformance Criteria

This specification is applicable to both user agents and hosting specifications. Hosting specifications are expected to indicate when the rules set forth by this specification are to be followed. (Typically this would involve using the cross-site access request algorithm for non same origin requests.

As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

In this specification, The words must, must not, should, should not and may are to be interpreted as described in RFC 2119. [RFC2119]

A conformant hosting specification is one that implements all the requirements listed in this specification that are applicable to hosting specifications. For instance, such a specification needs to define what the source for the source origin is.

A conformant user agent is one that implements all the requirements listed in this specification that are applicable to user agents, while also being consistent with the requirements listed in the hosting specification.

User agents may employ any algorithm to implement this specification, so long as the end result is indistinguishable from the result that would be obtained by the specification's algorithms.

2.1 Terminology

Terminology is generally defined throughout the specification. However, the few definitions that did not really fit anywhere else are defined here instead.

There is a case-insensitive match of strings s1 and s2 if after mapping the ASCII character range A-Z to the range a-z both strings are identical.

The terms URL, origin, ASCII serialization of an origin, and same origin are defined by HTML 5. [HTML5]

3. Security Considerations

The cross-site access request algorithm defined in this specification is an extension of the same origin policy in contexts where the same origin policy currently applies. This impacts hosting specifications referencing the algorithm, user agents implementing it, and authors using it. Below we discuss the security considerations for these groups.

Hosting specifications

Hosting specifications should limit the request headers an author can set and get, and forbidding setting and getting user credentials through any API defined in the hosting specification.

For instance, access to document.cookie of the requested resource is to be prohibited.

Hosting specifications using the cross-site access request should properly deal with redirects. In particular, if a same origin request is redirected to a non same origin URL the specification should abort the request and either terminate completely (as it did until now) or use the cross-site access request algorithm on the non same origin URL.

These requirements are further detailed in the processing model section.

User agents

When making a cross-site access request, user agents should ensure to:

• Not reveal whether the requested resource exists, until access has been granted. This prevents port scanning and finding out about intranet servers the user might be connected with.

• Not inappropriately expose any trusted data of the response, such as cookies and HTTP header data.

• Not allow the author to set cookies or authentication credentials for the request, as this would allow for a distributed cookie or credentials search. Either through letting them set HTTP headers or providing the userinfo production in redirects. (This last concern is mitigated by the algorithms in present in this specification.)

Authors

Application authors should be aware that content retrieved from another site is not itself trustable. Authors should protect themselves against cross-site scripting attacks by not rendering or executing the retrieved content directly without validating that content.

Authors are to ensure that GET requests on their applications have no side effects. If by some means an attacker finds out what applications a user is associated with, it might "attack" these applications with GET requests that can effect the user's data (if the user is already authenticated with any of these applications by means of cookies or HTTP authentication).

Authors are strongly encouraged to check the Origin HTTP header, especially for non-GET requests, to ensure that in case of policy change they do not inadvertently allow access due to race conditions (when such access is to be denied).

Authors should also check the Host HTTP header and make sure the host name provided by that header matches the host name of their server. This will provide protection against DNS rebinding attacks.

For different authors sharing one host name (people.example.org/~author-name/) it is not possible to allow access only from a certain author as the other authors could trivially work around this through DOM scripting. Sharing access with an author who shares the host name with someone else is therefore discouraged.

Integrity protection of the access control policy statements may be required. This could be achieved by use of SSL/TLS, for example.

4. Syntax

This section defines the various syntactic constructs this specification introduces. A number of these constructs are defined using ABNF as defined in RFC 2616. [RFC2616].

RFC 2616 is used as ABNF basis to ensure that the new headers have equivalent constructs to those introduced in that specification.

4.1 Access-Control-Allow-Origin HTTP Response Header

A resource can have one Access-Control-Allow-Origin header defined. The header must match the following ABNF:

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" ascii-origin | "*"
ascii-origin                = ASCII serialization of an origin

Access-Control-Allow-Origin: http://example.org

Access-Control-Allow-Origin: *

4.2 Access-Control-Max-Age HTTP Response Header

The Access-Control-Max-Age HTTP response header indicates how long the results of a preflight request can be cached in a preflight result cache. The Access-Control-Max-Age HTTP header must match the following ABNF:

Access-Control-Max-Age = "Access-Control-Max-Age" ":" delta-seconds

The delta-seconds production is defined in RFC 2616. [RFC2616]

4.3 Access-Control-Allow-Credentials HTTP Response Header

The Access-Control-Allow-Credentials HTTP response header indicates whether the response to request can be exposed when the credentials flag is true. When part of the response to an preflight request it indicates that the actual request can be made with credentials. The Access-Control-Allow-Credentials HTTP header must match the following ABNF:

Access-Control-Allow-Credentials: "Access-Control-Allow-Credentials" ":" "true"

4.4 Access-Control-Allow-Methods HTTP Response Header

The Access-Control-Allow-Methods HTTP response header indicates, as part of the response to a preflight request, which HTTP methods can be used during the actual request. The Access-Control-Allow-Methods HTTP header must match the following ANBF:

Access-Control-Allow-Methods: "Access-Control-Allow-Methods" ":" #Method

The Method production is defined in RFC 2616. [RFC2616]

4.5 Access-Control-Allow-Headers HTTP Response Header

The Access-Control-Allow-Headers HTTP response header indicates, as part of the response to a preflight request, which HTTP headers can be used during the actual request. The Access-Control-Allow-Methods HTTP header must match the following ANBF:

Access-Control-Allow-Headers: "Access-Control-Allow-Headers" ":" #field-name

The field-name production is defined in RFC 2616. [RFC2616]

4.6 Origin HTTP Request Header

The Origin HTTP request header indicates where the cross-site access request or preflight request originates from. The Origin HTTP header must match the following ABNF:

Origin = "Origin" ":" source origin

The source origin can be the empty string. When the source originates from a data: URL for instance.

In contrast with the Referer header, Origin does not reveal confidential path information and does therefore not need to be disabled.

This header has a generic name as it is likely that other APIs will start using it too.

4.7 Access-Control-Request-Method HTTP Request Header

The Access-Control-Request-Method HTTP request header indicates what HTTP method will be used in the actual request as part of the preflight request. The Access-Control-Request-Method HTTP header must match the following ABNF:

Access-Control-Request-Method: "Access-Control-Request-Method" ":" Method

4.8 Access-Control-Request-Headers HTTP Request Header

The Access-Control-Request-Headers HTTP request header indicates what HTTP headers will be used in the actual request as part of the preflight request. The Access-Control-Request-Method HTTP header must match the following ABNF:

Access-Control-Request-Headers: "Access-Control-Request-Headers" ":" #field-name

5. Processing Model

This section (including subsections) describes the processing models that user agents and hosting specifications have to implement. A hosting specification "implements" an algorithm by referencing it and carefully defining how the return values are handled.

5.1 Cross-Site Access Request

The cross-site access request algorithm takes the following parameters:

• A request URL.

  The request URL is modified in face of redirects.

• A request method.

• A collection of additional request headers.

• A request entity body.

• A source for the source origin.

• A credentials flag.

The return values are described further down. The cross-site access request algorithm can be used by hosting specifications who wish to provide cross-site requests for the APIs they define.

Hosting specifications are free to limit the abilities of a cross-site access request. E.g., the credentials flag could always be false.

When the cross-site access request algorithm is used, these steps must be followed:

1. If request method is equal to GET or POST, the collection of request headers contains no other headers than those of the simple request header whitelist, and if the Content-Type header, when part of request headers while the request method is POST, contains no values other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, then follow the simple cross-site access request algorithm.

2. Otherwise, follow the cross-site access request with preflight algorithm.

Cross-Site requests using the GET or POST method with request headers other than those in the simple request header whitelist will have a preflight request to ensure that the server is can handle those headers. (Similarly to requests using methods other than GET or POST.)

User agents must filter out all response headers other than those listed in the response header whitelist before exposing response headers to the APIs defined in the hosting specification.

The getResponseHeader() method defined by XMLHttpRequest for instance will therefore not get access to the Cookie2 header and other headers not part of the whitelist.

The aforementioned algorithms have shared return values that hosting specifications can use to instruct user agents what to do. The status return flag indicates the status of the cross-site access request. It takes the value "success" when cross-site access to the resource is allowed, "same-origin" if the cross-site request turned into a same origin request due to redirects, "network" if a network error of some sort occurred, and "abort" if the user aborted the request. The url return flag is used when the status return flag is "same-origin", to indicate the URL which the specification can use for a subsequent same origin request.

When used by hosting specifications, those specifications must handle all values of the status return flag and handle the url return flag.

5.1.1 Cross-Site Access source origin

The source origin is the ASCII serialization of the origin of the source of the request.

Hosting specifications using cross-site access requests must define the source of the request for the source origin. Due to the way the origin for APIs is retrieved in different ways, it is not possible to define this in a generic way.

While following the requirements for cross-site access requests, user agents must ensure that for each request (including redirects, et cetera) the Origin HTTP request header is set, with the value set to access control origin.

5.1.2 Cross-Site Access Request Header Lists

The simple request header whitelist consists of all headers of which the header name case-insensitively matches one of the following:

• Accept
• Accept-Language
• Content-Type

The response header whitelist consists of all headers of which the header name case-insensitively matches one of the following:

• Cache-Control
• Content-Language
• Content-Type
• Expires
• Last-Modified
• Pragma

5.1.3 Simple Cross-Site Access Request

The steps below describe what user agents must do for a simple cross-site access request:

1. Apply the make a request steps and observe the request rules below while making the request.

   If the response is an HTTP redirect

   Apply the redirect steps.

   If the user cancels the request

   Apply the abort steps.

   If there is a network error

   Apply the network error steps.

   Otherwise

   Perform an access control check. If it returns "fail", apply the network error steps. Otherwise, if it returns "pass", terminate this algorithm and return with the status flag set to "success". Do not actually terminate the request.

5.1.4 Cross-Site Access Request with Preflight

To protect servers against cross-site access with methods that have side effects an preflight request is made to ensure that the server is ok with the request. The result of this request is stored in an preflight result cache.

As mentioned, cross-site access request with preflights use an preflight result cache. This cache consists of a set of entries. Each entry consists of the following fields:

origin

Holds the source origin.

url

Holds the request URL.

expiry time

Holds the Access-Control-Max-Age header value.

credentials

Holds the value of the credentials flag.

methods

Holds the list of values from the Access-Control-Allow-Methods headers.

headers

Holds the list of values from the Access-Control-Allow-Headers headers.

Entries must be removed when the time specified in the expiry time field has passed since storing the entry. Entries can also be added and removed per the algorithms below. They are added and removed in such a way that there can never be duplicate items in the cache.

The steps below describe what user agents must do for cross-site access request with preflights. These are requests to a non same origin URL with an HTTP request method other than GET that first need to be authorized using either a preflight result cache entry or a preflight request.

1. If there is an entry in the preflight result cache that matches the conditions described in the list below proceed to the next step:

   • The origin field value is identical to the source origin.

   • The url field value is identical to the request URL.

   • If the credentials flag is true, the credentials field value is identical to the credentials flag.

   • One of the values of the method field is identical to the request method, or the request method is GET or POST.

     HTTP methods are case-sensitive.

   • Every header name of request headers case-insensitively matches a header of the headers field or is in the simple request header whitelist.

   Otherwise, remove the cache entry, if any, and then make a preflight request. This is a request using the HTTP OPTIONS method to the request URL. In addition to normal request headers and the Origin header, user agents are also to include an Access-Control-Request-Method header with as value the request method, and an Access-Control-Request-Headers header with as value a comma-separated list of header names from request headers. (No credentials, entity body, et cetera, are to be included.) Observe the following request rules while making this request:

   If the response is an HTTP redirect

   Apply the redirect steps.

   If the user cancels the download

   Apply the abort steps.

   If there is a network error

   Apply the network error steps.

   Otherwise

   1. If the access control check returns "fail", apply the network error steps.

   2. Let methods be the result of parsing the Access-Control-Allow-Methods header values. If parsing fails (e.g., value with a space), apply the network error steps.

   3. Let headers be the result of parsing the Access-Control-Allow-Headers header values. If parsing fails, apply the network error steps.

   4. If request method is not identical to any method in methods, or is not identical to GET or POST, apply the network error steps.

   5. If every single header name of request headers does not case-insensitively matches a header name in headers or is not in the simple request header whitelist, apply the network error steps.

   6. Append a cache entry.

      If the credentials flag is false, the cache entry will not have the credentials field value set to true, regardless of whether a Access-Control-Allow-Credentials header was present in the response.

2. This is the actual request. Apply the make a request steps and observe the request rules below while making the request.

   If the response is an HTTP redirect

   First remove the cache entry and then apply the network error steps.

   If the user cancels the download

   Apply the abort steps.

   If there is a network error

   Apply the network error steps.

   Otherwise

   Perform an access control check. If it returns "fail", remove the cache entry, then apply the network error steps. Otherwise, if it returns "pass", terminate this algorithm and return with the status flag set to "success". Do not actually terminate the request.

5.1.5 Generic Cross-Site Access Request Algorithms

The variables used in the generic set of steps are part of the algorithms that invoke these set of steps.

Whenever the make a request steps are applied, make a request to request URL, using HTTP method request method, entity body request entity body, including the additional request headers, and include credentials if the credentials flag is true (e.g. HTTP authentication data and cookies).

The redirect steps are as follows:

If the new URL scheme is not supported, infinite loop precautions are violated, or something else went wrong, apply the network error steps. Otherwise, let request URL be the new URL and then follow this set of steps:

1. If the request URL contains the userinfo production, as defined in section 3.2.1 of RFC 3986, apply the network error steps. [RFC3986]

2. If request URL and source origin are same origin, terminate the algorithm that invoked this set of steps and return with the url flag set to the request URL and the status flag set to "same-origin".

3. If the access control check for the current resource returns "fail", apply the generic network steps.

4. Otherwise, transparently follow the redirect while observing the set of request rules.

Whenever the abort steps are applied, terminate the algorithm that invoked this set of steps and return with the status flag set to "abort".

Whenever the network error steps are applied, terminate the algorithm that invoked this set of steps and return with the status flag set to "network".

Remove the cache entry means removing the entry in the preflight result cache where source origin is identical to the origin field value and request URL is identical to the url field value.

To append a cache entry means to follow this set of steps:

1. If for some reason the user agent is unable to provide a cache terminate this set of steps.

2. Create a new entry in the preflight result cache with the various fields set as follows:

   origin

   source origin.

   url

   request URL.

   expiry time

   If there is a single Access-Control-Max-Age response header with a correct value, the value of the Access-Control-Max-Age response header. Otherwise, a value at the discretion of the user agent (which can be zero).

   credentials

   credentials flag.

   methods

   methods (see preflight request).

   headers

   headers (see preflight request).

5.2 Access Control Check

The access control check algorithm for a given resource is as follows:

1. If the resource includes zero or more than one Access-Control-Allow-Origin headers return "fail" and terminate this algorithm.

2. If the Access-Control-Allow-Origin header value is the literal "*" character and the credentials flag is false return "pass" and terminate this algorithm.

3. If the value of Access-Control-Allow-Origin is not identical to the source origin return "fail" and terminate this algorithm.

4. If the credentials flag is true and the resource includes zero or more than one Access-Control-Allow-Credentials headers return "fail" and terminate this algorithm.

5. If the credentials flag is true and the Access-Control-Allow-Credentials header value is not the literal string "true" return "fail" and terminate this algorithm.

6. Return "pass".

Requirements

While the requirements use "normative" terminology this appendix does not affect conformance and is therefore non-normative.

The requirements that influenced the design of the Access Control for Cross-Site Requests specification are as follows:

1. Must not introduce new attack vectors, such as:

   1. Must not introduce attack vectors to servers that are only protected only by a firewall.

      The solution should not introduce additional attack vectors against services that are protected only by way of firewalls. This requirement addresses "intranet" style services authorize any requests that can be sent to the service.

      Note that this requirement does not preclude HEAD, OPTIONS, or GET requests (even with ambient authentication and session information).

   2. It should not be possible to perform cross-site non-safe operations, i.e., HTTP operations except for GET, HEAD, and OPTIONS, without an authorization check being performed.

   3. Should try to prevent dictionary-based, distributed, brute-force attacks that try to get login accounts to 3^rd party servers, to the extent possible.

   4. Should properly enforce security policy in the face of commonly deployed proxy servers sitting between the user agent and any of servers with whom the user agent is communicating.

   5. Should not allow loading and exposing of resources from 3^rd party servers without explicit consent of these servers as such resources can contain sensitive information.

2. Must not require content authors or site maintainers to implement new or additional security protections to preserve their existing level of security protection.

3. Must be deployable to IIS and Apache without requiring actions by the server administrator in a configuration where the user can upload static files, run serverside scripts (such as PHP, ASP, and CGI), control HTTP headers, and control authorization, but only do this for URLs under a given set of subdirectories on the server.

4. Must able to deploy support for cross-site GET requests without having to use server-side scripting (such as PHP, ASP, or CGI) on IIS and Apache.

5. The solution must be applicable to arbitrary media types. It must be deployable without requiring special packaging of resources, or changes to resources' content.

6. It should be possible to configure distinct cross-site authorization policies for different target resources that reside within the same origin.

7. It should be possible to distribute content of any type. Likewise, it should be possible to transmit content of any type to the server if the API in use allows such functionality.

8. It should be possible to allow only specific servers, or sets of servers to fetch the resource.

9. Must not require that the server filters the entity body of the resource in order to deny cross-site access to all resources on the server.

10. Cross-site requests should not require API changes other than allowing cross-site requests. This means that the following examples should work for resources residing on http://test.example (modulo changes to the respective specifications to allow cross-site requests):

    • <?xml-stylesheet type="application/xslt+xml" href="http://example.org/annotate.xslt"?>

    • <?xbl href="http://example.org/globe.xml"?>

    • xhr = new XMLHttpRequest();
      xhr.open("GET", "http://example.org/data.text");
      xhr.send();

11. It should be possible to issue methods other than GET to the server, such as POST and DELETE.

12. Should be compatible with commonly used HTTP authentication and session management mechanisms. I.e. on an IIS server where authentication and session management is generally done by the server before ASP pages execute this should be doable also for requests coming from cross-site requests. Same thing applies to PHP on Apache.

13. Should reduce the risk of inadvertently allowing access when it is not intended. This is, it should be clear to the content provider when access is granted and when it is not.

Use Cases

The use cases appendix documents several potential use cases that guided development of the Access Control work. This appendix does not affect conformance and is therefore non-normative.

• If the contacts part of an e-mail application allows a social networking site to add contacts this could be done through a cross-site PUT requests.

• If a server foo.example.org implements a simple REST API to create, delete and modify resources Access Control could be used to let a nice editing application on server editing.example store the results of the editing actions on foo.example.org.

• An XBL binding allows full access to the document it is bound to and therefore cross-site XBL usage is prevented. Access Control enables cross-site XBL bindings. If the user is authenticated with the server that hosts the XBL widget it is possible to have a user-specific cross-site bindings.

• To prevent data theft, from e.g. intranets, cross-site XSLT usage is not possible. With Access Control several domains are able to share XSLT resources in a cross-site fashion.

• If you have a Web application that fetches resources (e.g. RDF) from around the Web to extract data out of them Access Control could be used to fetch them using a single request if the resource enables cross-site access.

Design Decision FAQ

This appendix documents several frequently asked questions and their corresponding response. As it does not affect conformance it is non-normative.

Why is there a preflight request?

For most type of requests two access control checks are performed. Initially a "permission to make the request" check is done on the response to the preflight request. And then a "permission to read" check is done on the response to the actual request. Both of these checks need to succeed in order for success to be relayed to the API (e.g. XMLHttpRequest).

The "permission to make the request" check is performed because deployed servers do not expect such cross-site requests. E.g., a request using the HTTP DELETE method. If they reply positively to the preflight request the client knows it can go ahead and perform the actual desired request.

Why is POST treated identically to GET?

Cross-site POST requests have long been possible using the HTML form element. Cross-site POST requests with arbitrary an Content-Type header set have been possible for a long time in Flash.

Why are cookies and authentication information sent in the request?

Sending cookies and authentication information enables user-specific cross-site widgets (external XBL file). It also allows for a user authenticated data storage API that services can use to store data in.

Cookies and authentication information is already sent cross-site for various HTML elements, such as img, script, and form.

Why can cookies and authentication information not be provided by the script author for the request?

This would allow dictionary based, distributed, cookies / user credentials search.

Why is the client the policy enforcement point?

The client already is the policy enforcement point for these requests. The mechanism allows the server to opt-in to let the client expose the data. Something clients currently not do and which servers rely upon.

Note however that the server is in full control. Based on the value of the Origin header in cross-site requests it can decide to return no data at all or not provide the necessary handshake (the Access-Control-Allow-Origin header).

What about the JSONRequest proposal?

JSONRequest has been considered by the Web Applications Working Group and the group has concluded that it does not meet the documented requirements. E.g., requests originating from the JSRONRequest API cannot include credentials and JSONRequest is format specific.

References

[HTML5]

HTML 5 (work in progress), I. Hickson, D. Hyatt, editors. W3C, 2008.

HTML 5 (work in progress), I. Hickson, editor. WHATWG, 2008.

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997.

[RFC2616]

Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, editors. IETF, June 1999

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, editors. IETF, January 2005.

Acknowledgments

The editor would like to thank Adam Barth, Arthur Barstow, Benjamin Hawkes-Lewis, Björn Höhrmann, Cameron McCormack, Collin Jackson, David Håsäther, David Orchard, Dean Jackson, Eric Lawrence, Frank Ellerman, Frederick Hirsch, Graham Klyne, Hal Lockhart, Henri Sivonen, Ian Hickson, Jonas Sicking, Lachlan Hunt, Maciej Stachowiak, Marc Silbey, Marcos Caceres, Mark Nottingham, Martin Dürst, Matt Womer, Michael Smith, Mohamed Zergaoui, Sharath Udupa, Sunava Dutta, Surya Ismail, Thomas Roessler, Tyler Close, and Zhenbin Xu for their contributions to this specification.

Special thanks to Brad Porter, Matt Oshry and R. Auburn, who all helped editing earlier versions of this document.