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.


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.

  • Does probe.domainE.domainD.domainA.com serve the response with the Access-Control-Allow-Origin header? Nov 27, 2015 at 3:39
  • @rink.attendant The probe's response to the beacon is served with the Access-Control-Allow-Origin header but that shouldn't make a difference?
    – bcooper
    Nov 27, 2015 at 4:42
  • @bcooper: That's why it works if it is served with the ACAO header. Nov 30, 2015 at 10:09

1 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.

Flowchart showing how a browser decides whether to use a Simple XHR or a Preflighted XHR when making a Cross-Origin XHR call. (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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .