Configure beacon origin allowlist for web applications
Use the beacon origin allowlist to specify the origins from which your application beacon endpoints should accept cross-origin RUM beacons.
Same- and cross-origin beacons
Auto-injected applications > same-origin beacons
By default, the beacons of auto-injected applications are same-origin beacons since the protocol, host, and port of the beacon requests and the page where they're issued are identical.
If you opted for one of the alternative beacon endpoint setups—where the beacons of an auto-injected application are sent to the Dynatrace SaaS infrastructure, a Cluster ActiveGate, or an instrumented server on a different domain—RUM beacons are cross-origin beacons.
Agentless applications > cross-origin beacons
When agentless monitoring is used, RUM beacons are sent to a beacon endpoint that is either part of the Dynatrace SaaS infrastructure (for Dynatrace SaaS) or a Cluster ActiveGate (for Dynatrace Managed).
For agentless applications, the RUM beacons are cross-origin beacons since they're sent to a different domain.
Browsers adhere to the same-origin policy that, by default, allows scripts to issue requests only to the same origin. To send cross-origin requests, Cross-Origin Resource Sharing (CORS) needs to be used, which allows servers to specify origins that are permitted to access the server. Therefore, cross-origin RUM beacons need to use CORS. In this case:
- The browser adds an
Originheader to the cross-origin beacon.
- By default, the beacon endpoint adds an
Access-Control-Allow-Originheader to each response that allows the origin provided in the
Using the beacon origin allowlist, you can specify from which origins your beacon endpoints should accept RUM beacons.
Specify beacon origins for CORS
Create a beacon origin rule to specify from which origins the OneAgent, Dynatrace SaaS infrastructure, and Cluster ActiveGate should accept RUM beacons.
Right after you add the first beacon origin rule, applications that don't match that rule will stop collecting RUM data unless they're auto-injected applications with same-origin beacons handled by OneAgent.
To add a beacon origin rule
In the Dynatrace menu, go to Settings > Web and mobile monitoring > Beacon origins for CORS.
Select Add item.
Provide the correct pattern for the origin you want to specify.
You can add up to 20 beacon origin rules per environment.
Application of beacon origin allowlist in different scenarios
This flowchart shows how Dynatrace applies the beacon origin allowlist in different scenarios. Use it to understand whether a specific beacon origin is allowed.
- If the beacon origin allowlist is empty, RUM beacons from any origin are accepted by all beacon endpoints.
- If an origin is on the allowlist, a RUM beacon from that origin is accepted. In the cross-origin case, the origin is copied to the
Access-Control-Allow-Originheader of the response, and the beacon response returns the
200 OKHTTP status code.
- If an origin is not on the allowlist, a cross-origin RUM beacon from that origin is rejected. The beacon fails with the
403 Forbiddenstatus code and a message such as
Value in Origin Header is not allowed.
- OneAgent doesn't apply the beacon origin allowlist to same-origin beacons.
Access-Control-Allow-Origin header to these requests.
For auto-injected applications, update OneAgent to eliminate the
Access-Control-Allow-Origin header. Starting with OneAgent version 1.215, OneAgent doesn't set this header for
Using an absolute URL to configure the beacon endpoint for same-origin beacons
By design, OneAgent doesn't apply the beacon origin allowlist to same-origin beacons, since the feature doesn't provide any value in this case.
If you notice any related issues, check the configuration explained in Modify the beacon endpoint URL. When you enter the beacon endpoint URL, it should be a relative or root-relative URL. If you provide an absolute URL, the beacons will be sent in CORS mode even though they're same-origin beacons, and OneAgent will apply the beacon origin allowlist to them.