Summary

  • W3C's February 2007 access-control draft explored letting a resource author relax the browser's cross-site reading boundary. By March 2009, a Working Draft carried the Cross-Origin Resource Sharing name and developed an HTTP-header conversation between requesting origin, resource and browser.
  • The 16 January 2014 CORS Recommendation described a resource's Access-Control-Allow-Origin response and the browser's matching check. For certain methods or request headers, an OPTIONS preflight asks what the resource will accept before the main request proceeds.

Imagine two sites on opposite sides of a narrow street. One page has a weather chart; the other has the measurements. The chart would like to read the measurements directly, but the browser's same-origin boundary keeps a script from treating every neighbor's response as its own. The resource owner can choose whom to invite. The browser checks the invitation before carrying the answer across the street. This is the part of CORS that made a simple question — may this page read that data? — into a shared web mechanism.

An early version of the idea appears in the W3C Working Draft of 15 February 2007, Enabling Read Access for Web Resources. It proposed that a resource author could relax browser read restrictions with an HTTP header or an XML processing instruction. That proposal offered several kinds of host pattern and exception. It was a workshop for resource-side permission rather than the final CORS protocol. By the 17 March 2009 Cross-Origin Resource Sharing Working Draft, the conversation had moved toward the Origin request header, explicit allow headers in the response and the browser's checking steps.

The 16 January 2014 W3C Recommendation gives the guest list a precise form. The browser sends the requesting origin; a resource that chooses to share can answer with Access-Control-Allow-Origin naming that origin. The browser compares the response value with the origin of the requesting page. If the check passes, the client-side application may read the response. For a public resource with no access controls, the document also describes * as a broad invitation when credentials are omitted. A named invitation and a public invitation carry different choices by the resource owner.

Some requests need a conversation before the main visit. When a script wants a method or author-supplied headers outside the simple set, the 2014 rules provide a preflight: an OPTIONS request asks the destination which method and headers it will accept from that origin. The browser checks the answer and may keep it in a preflight cache for later use. That little knock happens for qualifying requests. A simple cross-origin request can already reach the resource; the browser's response-sharing check still decides whether the calling script gets to read what came back.

That distinction matters because server-side effects and response visibility are different decisions. A server may receive a request, process it and apply its own authorization rules. The CORS check governs whether the browser exposes the response to the other site's script. The 2014 Recommendation's security discussion explicitly separates authorizing a request and its side effects from authorizing access to the representation returned. A publisher cannot use an invitation header as a substitute for deciding whether a money-moving or account-changing request should be honored. The browser's guest list controls a particular crossing; the server still runs its own house.

Credentials make the invitation more specific. In the 2014 resource-sharing check, a credentialed request requires a matching origin and an Access-Control-Allow-Credentials: true response. The broad * case belongs to requests where credentials are omitted. These details keep the resource owner in charge of how widely a response can be read. The origin named in the header is a statement about the calling page's address, while the server's ordinary authorization must still consider the user and the requested action.

The W3C publication history traces the 2007 drafts through the 2014 Recommendation announcement and records the Recommendation's retirement in 2020. The historical mechanism had a clear center: a resource tells the browser which origins may see its response; the browser enforces that choice for client-side code. The neighbor could share the measurements without surrendering the entire house. The chart could finally draw its line, provided it had an invitation worth showing.