Configure RUM cookie attributes in the New RUM Experience

Latest Dynatrace
How-to guide
Published Apr 27, 2026

Dynatrace Real User Monitoring uses a set of HTTP cookies; see Cookies and web storage for RUM and Session Replay. You can customize some of the cookie attributes.

To access these options

Go to Experience Vitals > Overview.
Select Web to view all web frontends.
Select the frontend you want to configure.
On the Settings tab, select Open in Settings.
Go to Collect and capture > Frontend > Injection > Cookie.

The following sections describe the available settings.

Configure cookie attributes relevant to data privacy

If your company's security policy requires the Secure and SameSite cookie attributes, you need to configure RUM to set them, because they aren't set by default.

Dynatrace RUM does not support the HttpOnly attribute. Since HttpOnly cookies are inaccessible to JavaScript, the RUM JavaScript cannot read or modify them. Ensure that your infrastructure doesn't add the HttpOnly attribute, because this will break monitoring.

Set the Secure attribute

The Secure cookie attribute ensures that browsers send cookies only over secure connections.

Before enabling the Secure cookie attribute, ensure that your application is served entirely over secure connections. Otherwise, you'll lose visibility into any unencrypted HTTP communication.

To set the Secure cookie attribute, turn on Cookie > Use the Secure cookie attribute for cookies set by Dynatrace.

Set the SameSite attribute

The SameSite cookie attribute controls whether the browser sends the cookie with cross-site requests. For a detailed explanation of this attribute and its values, see SameSite cookies explained.

To set the SameSite cookie attribute, go to Cookie > SameSite cookie attribute and select one of the values None, Lax, and Strict.

The Domain and Path cookie attributes define a cookie's scope. This scope determines whether browsers send the cookie with a request and whether client-side JavaScript can access it for a given URL.

Dynatrace always sets the Path attribute of the RUM cookies to /, so the cookie scope covers all URL paths within a domain. The Path attribute cannot be configured.
By default, the Domain attribute is determined automatically, but you can also configure it manually for each frontend.

The following sections explain how Dynatrace determines the default cookie domain and when you might need to configure it manually.

By default, Dynatrace determines the cookie domain automatically by choosing the effective top-level domain plus one (eTLD+1) of the request URL. For example, Dynatrace chooses the example.com cookie domain for www.example.com and the example.co.uk cookie domain for www.example.co.uk. This allows Dynatrace to capture a continuous session even when users move between subdomains while interacting with your frontends, for example, from www.example.com to shop.example.com.

The cookie domain is determined either server-side by OneAgent or client-side by the RUM JavaScript.

If the RUM JavaScript is injected automatically, OneAgent usually determines the cookie domain, using the result of host name determination as a starting point. If an uninstrumented component rewrites the host portion of the URL, ensure that host name determination is configured correctly.
If you use agentless RUM, the RUM JavaScript determines the cookie domain.

In most scenarios, you don't need to configure the cookie domain manually. However, manual configuration is useful in the following cases:

You need to separate the user actions of different subdomains into separate user sessions.
Automatic cookie domain determination does not work because an uninstrumented component rewrites the host portion of the URL and does not forward the original host information in a request header. The preferred solution is to configure the component to add such a header; see Set up host name determination in the New RUM Experience. Manual cookie domain configuration is also a possible workaround.

To configure the cookie domain, go to Cookie > Domain to be used for cookie placement and enter the required domain.

Common pitfalls and limitations of manual configuration

Configured cookie domain is a public suffix

Browsers do not allow you to set cookies with a Domain attribute that exceeds a single organization's boundary. Therefore, setting the cookie domain to a public suffix does not work.

Multiple domains without a common eTLD+1 are mapped into the configured frontend

Since the cookie domain is configured per frontend, all domains that map to your frontend should share at least a common eTLD+1.

For example, you cannot manually configure the cookie domain for a frontend where both www.example.com and www.example.co.uk map. If you choose the cookie domain example.com, the browser rejects the RUM cookies on requests to www.example.co.uk.

Nested cookie domains

If you configure the cookie domain for all or some of your frontends manually, you must ensure that the cookie domains of your frontends are not nested.

Consider the following example. The www.example.com domain is mapped to the frontend Example, while the shop.example.com domain is mapped to the frontend Shop. By default, the example.com cookie domain is detected automatically for both frontends. If you manually set the cookie domain for Shop to shop.example.com and users navigate back and forth between the two frontends, ambiguous situations can arise. The RUM cookies for Example use the example.com cookie domain and therefore also apply to Shop, which has its own set of RUM cookies with the shop.example.com domain. With this configuration, Dynatrace might split the captured RUM data into short user sessions at random. In RUM Classic, user actions and distributed traces might not be linked as expected.