When is CORS applied?

Question

I'm including some RUM (Real User Monitoring) JavaScript on a client's website that beacons back performance info. I was expecting to run into CORS issues but it seems to be working without any warnings or errors.

Scenario

App - sit.domainC.domainB.domainA.com

Performance probe - probe.domainE.domainD.domainA.com

JS code is hosted on same domain as App.

1. Users visit app and work as normal
2. Javascript sends XHR to probe with performance data

The page isn't served with Access-Control-Allow-Origin so I'm not sure why this works.

Answer 1

CORS works by determining if the request target responds with an Access-Control-Allow-Origin (ACAO) header. In this case, the request target is the performance probe. It does not matter whether the page is served with an ACAO header.

From Wikipedia:

Note that in the CORS architecture, the ACAO header is being set by the external web service (bar.com), not the original web application server (foo.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application. For the latter, Content Security Policy should be used (connect-src directive).

Assuming that the same-origin policy is implemented correctly, a user agent (browser) that does not support CORS will simply produce an error when making a cross-origin request.

A user agent that supports CORS will make a cross-origin request with the Origin header containing a value of the site where the request is sent from and one of the following situations will happen:

• Response does not contain an Access-Control-Allow-Origin header. In this case, the browser will simply produce an error as the server does not allow for cross-origin requests.
• Response contains an Access-Control-Allow-Origin header with a value of *. In this case, the code will continue executing as any site is allowed to make a cross-origin request to the server.
• Response contains an Access-Control-Allow-Origin header with a list of origins. In this case, if the current site is in the list of origins then the code will continue executing as it is allowed to make a cross-origin request to the server. Otherwise, an error will be produced.

The above points are a slight oversimplification of the actual process. There can be more Access-Control-* headers involved.

For complex methods (i.e. non-simple methods) there is an extra step involved known as preflight in which a preflight request is made before the actual request.

Here is a flowchart that shows the process. The OPTIONS call represents the preflight process.

^{(Image used with permission, licensed under CC-BY-SA 4.0 by Bluesmoon [source])}

You can read more about using CORS on HTML5 Rocks. The CORS specification is pretty helpful as well, though the wording is technical because after all, it is the specification.