How does Access-Control-Allow-Origin header work?

Question

I have misunderstood its semantics. I thought  of something like this:

1. A client downloads javascript code MyCode.js from http://siteA - the origin

2. The response header of MyCode.js contains Access-Control-Origin : http://siteB, which I thought means that MyCode.js was allowed to make cross-origin references to the site B.

3. The client triggers some functionality of MyCode.js, which in turn make requests to http://siteB, which should be fine, despite being cross-origin requests.

It does not work like this at all. So, I read Cross-origin resource sharing and attempted to read Cross-Origin Resource Sharing in w3c recommendation,

One thing is for sure- I still do not understand how am I supposed to use this header.

I have full control of site A and site B. How do I enable the javascript code downloaded from site A to site B using this header?

Answer 1

Access-Control-Allow-Origin is a Cross-Origin Resource Sharing header. 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 origin, By default, Site B’s pages are not accessible to any other original; 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 a 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 requested 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:

• Using an HTTP verb other than GET or POST

• Using non-simple request headers; the only simple requests headers are:

  • Accept

  • Accept-Language

  • Content-Language

  • Content-Type

If the server responds to the OPTIONS preflight with appropriate response headers that match the non-simple verb and 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 senf a preflight request

OPTIONS /somePage HTTP/1.1

Origin: http://siteA.com

Access-Control-Request-Method: PUT

Access-Control-Request-Headers: Content-Type

When sending the actual request, 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.

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

Want to learn Full Stack Development? Check out the Full Stack Developer course from Intellipaat.