CORS error on agentless RUM page with JavaScript tag (missingAllowOriginHeader)

[fstekelenburg]

We are setting up an web based application (www.foobar.net) with Agentless real user monitoring, by manual insertion of the JavaScript tag. The website is public (external facing). A static landing page (www.foobar.net/some/testpage) is used to test. It contains a few third party references.

Verifying the working of the page and data collection we see the complete javascript being pulled correctly. (Using Edge browser, developer mode (F12))
A first xhr request to the public endpoint also completes.
A second xhr request fails with a CORS error, with detail "Cross-origin resource sharing error: missingAllowOriginHeader"

Question is what causes the CORS error, and more importantly what can be done to solve it?

It appears that only the 1st party data is received.  The app manager tried with settings like "Access-Control-Allow-Origin: *' with no success.

Details from F12 on the error line show:

1. Request URL: https://cag.foobar.net/bf/***rest***
2. Referrer Policy:
   strict-origin-when-cross-origin

From the page CORS Amazon S3 | Dynatrace Help (https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/config...) I learned that "Unfortunately Internet Explorer 11 and Edge don't currently support the crossorigin attribute." So I checked with Firefox, and there the issue seems not to appear. (Chrome has same result as Edge)

Note: The Cluster Activate URL is set to a public URL (eg. cag.foobar.net:443), serviced by a load-balancer and forwarded to two CAGs (in DMZ). 

The option Add the crossorigin=anonymous attribute to capture JavaScript error messages and W3C resource timings of the JavaScript tag has been enabled, resulting in the extra parameter crossorigin="anonymous"

[fstekelenburg]

Noteworthy to mention is that with Chromium browsers (Edge, Chrome) this error is noticed.
But not with Firefox or IE.

From an internal system with Chrome it works without errors, but the 3rd party objects are not reachable there.

[fstekelenburg · Accepted solution]

As it turns out F5 LTM loadbalancer did not change/removed the headers in http

F5 (Big-IP) ASM (Application Security Manager), a web application firewall (WAF)
however ASM can, and does.  With ASM temporary disabled on the AG traffic, it works.

Instead of writing an iRule in ASM, the admin increased the maximum URL length from the default 2048 bytes to 5000 bytes first. As it appears the beacon URLs can be longer than 2K.

Support confirmed that on the /jstag and /bf endpoints, the Access-Control-Allow-Origin header is present if its a valid request to it.

This actually applies also to receiving Synthetic monitoring data in Managed.

Configuring the maximum allowed URL length for an HTTP request (f5.com)