Difference between revisions of "Origin Access Control"

Latest revision as of 22:42, 27 January 2024

Full Title or Meme

Access-Control-Allow-Origin is a CORS (cross-origin resource sharing) header.

Context

When Site A tries to fetch content from Site B, Site B can send an Access-Control-Allow-Origin response header to tell the browser that the content of this page is accessible to certain origins. (An origin is a domain, plus a scheme and port number.) By default, Site B's pages are not accessible to any other origin; using the Access-Control-Allow-Origin header opens a door for cross-origin access by specific requesting origins.

For each resource/page that Site B wants to make accessible to Site A, Site B should serve its pages with the response header:

Access-Control-Allow-Origin: http://siteA.com
Modern browsers will not block cross-domain requests outright. If Site A requests a page from Site B, the browser will actually fetch the requested page on the network level and check if the response headers list Site A as a permitted requester domain. If Site B has not indicated that Site A is allowed to access this page, the browser will trigger the XMLHttpRequest's error event and deny the response data to the requesting JavaScript code.

Non-simple requests
What happens on the network level can be slightly more complex than explained above. If the request is a "non-simple" request, the browser first sends a data-less "preflight" OPTIONS request, to verify that the server will accept the request. A request is non-simple when either (or both):

using an HTTP verb other than GET or POST (e.g. PUT, DELETE)
using non-simple request headers; the only simple requests headers are:
Accept
Accept-Language
Content-Language
Content-Type (this is only simple when its value is application/x-www-form-urlencoded, multipart/form-data, or text/plain)
If the server responds to the OPTIONS preflight with appropriate response headers (Access-Control-Allow-Headers for non-simple headers, Access-Control-Allow-Methods for non-simple verbs) that match the non-simple verb and/or non-simple headers, then the browser sends the actual request.

Supposing that Site A wants to send a PUT request for /somePage, with a non-simple Content-Type value of application/json, the browser would first send a preflight request:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically; you do not need to add them. This OPTIONS preflight gets the successful response headers:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
When sending the actual request (after preflight is done), the behavior is identical to how a simple request is handled. In other words, a non-simple request whose preflight is successful is treated the same as a simple request (i.e., the server must still send Access-Control-Allow-Origin again for the actual response).

The browsers sends the actual request:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }
And the server sends back an Access-Control-Allow-Origin, just as it would for a simple request:

Access-Control-Allow-Origin: http://siteA.com

See Understanding XMLHttpRequest over CORS for a little more information about non-simple requests.

Taxonomy

HTTP response data is the data sent by a server to a client in response to an HTTP request. It contains information about the status of the request and may also contain the requested content in its body. The response data is usually sent in the form of a message, which includes a status code and a status message1. The status code is a three-digit number that indicates the status of the request, such as whether it was successful or not. The status message is a short description of the status code.^[1]

CORS

Cross-Origin Resource Sharing (CORS) is a mechanism that allows restricted resources on a web page to be accessed from another domain outside the domain from which the first resource was served. CORS is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. This mechanism relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

CORS failures result in errors but for security reasons, specifics about the error are not available to JavaScript. All the code knows is that an error occurred 1. The only way to determine what specifically went wrong is to look at the browser’s console for details.^[2]

COEP

Cross-Origin-Embedder-Policy (COEP) is an HTTP-header based mechanism that allows a server to indicate any origins other than its own from which a browser should permit loading resources. COEP is used to prevent a document from loading cross-origin resources that don’t explicitly grant the document permission with Cross-Origin-Resource-Policy (CORP) or Cross-Origin Resource Sharing (CORS). COEP lets you declare that a document cannot load these resources.^[3]

Problems

Origin Access Control was instantiated to improve the privacy of the browser users. It had subsidiary impact on the security of existing security protocols like OpenID Connect

The browser changes from 2020 to cookie sameSite properties also made it so that a server that wishes to support POST at its authorization endpoint needs to relax its cookie settings to sameSite: "none" explicitly in order for the received POST request to carry the server's previous cookies. This is unfortunate because the default "lax" behavior is generally more secure and aids in limiting unintended exposure to cross site request forgery.

• Get Ready for New SameSite=None; Secure Cookie Settings 2020-01-26 from Google. With Chrome 80 in 2020-02, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies.

References

1. ↑ Mozilla, HTTP response status codes https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
2. ↑ Mozilla, Cross-Origin Resource Sharing (CORS) https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
3. ↑ Mozilla, Cross-Origin-Embedder-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy

Other Materiel

• from stack overflow with lots of germane responses.
• See wiki page on Cross-Origin iFrame