Contently
Start a conversation Sign in
Start a conversation
  1. Contently
  2. Contently Articles
  3. Articles

Understanding the "dd-api-key" Value Visible in Browser Developer Tools (Datadog Browser RUM Client Token)

  1. ATLAS KBA

  2. Posted
  3. Updated

Contents

Overview

While using the web application, a security reviewer may notice an API-key-like value — a parameter named dd-api-key — exposed in the browser's Developer Tools / network logs, and raise a concern that a credential is leaking client-side.

Investigation, verified against production frontend code and observed network behavior, confirmed that this value is a Datadog Browser RUM (Real User Monitoring) client token — not an application API credential. It appears on Datadog RUM and session-replay telemetry requests, which return HTTP 202 when the telemetry is accepted. Datadog Browser RUM client tokens are intentionally visible in browser-side applications by design, and this specific token type cannot be used to sign in, access application content, retrieve monitoring data, or change any Datadog configuration. No security risk and no application-security remediation is required solely because this token is visible in Developer Tools.

Key Information

  • What the value is: The dd-api-key parameter observed on outbound requests to Datadog RUM and session-replay endpoints is a Datadog Browser RUM client token. The web client uses it to initialize browser diagnostics and session-replay telemetry.
  • It is not an application API credential. Its only purpose is to associate submitted browser telemetry with a specific RUM application.
  • Its visibility is expected. Datadog documents that this token type is intentionally visible in browser-side applications, because browser-based telemetry runs in the client and the token must be present there to submit data. This is fundamentally different from a Datadog API key (which grants access and must never be exposed in a browser).
  • What this token cannot do:
    • It does not provide any way to sign in to the application.
    • It does not allow access to application content or customer data.
    • It does not allow retrieval of RUM / monitoring data.
    • It does not allow changing any Datadog configuration.
  • No application secret is exposed by its presence in Developer Tools.
  • Optional token management (not a security fix): Datadog recommends managing client tokens through token rotation and bot filtering to reduce unwanted telemetry submissions. These measures affect telemetry ingestion only; they do not change the token's inability to access customer or administrative data.

How to Verify You Are Looking at a RUM Client Token

To confirm that the value you observed is the harmless Datadog Browser RUM client token — and not a genuinely sensitive credential — check the following in your browser's Developer Tools Network tab (open with Ctrl+Shift+I on Windows/Linux or Cmd+Option+I on Mac, then select the Network tab):

  1. Check the endpoint host. Confirm the request carrying the value is going to a Datadog RUM / session-replay telemetry endpoint, not to an application or administrative API endpoint.
  2. Check the request status. Accepted telemetry submissions typically return HTTP 202.
  3. Check the parameter/header name. The value appears as the dd-api-key parameter on Datadog telemetry requests. In a Datadog RUM context, this naming indicates a client token, not an API key.
  4. Confirm it is not a different credential type. A genuinely sensitive value would instead appear as, for example, an Authorization: Bearer ... header, a full X-API-Key header, or a request to a non-Datadog endpoint. Any of those require separate assessment (see below).

Customer Impact

No action is required. The visibility of the Datadog Browser RUM client token in Developer Tools is expected behavior and does not represent a credential leak or security risk. No application-security remediation is needed.

If you choose to manage the client token (rotation, bot filtering), do so only to control unwanted telemetry ingestion — it is not necessary for security and does not change what the token can access.

If You Believe You Observed a Different Value

If your review identifies a value other than the Datadog RUM client token — for example, an Authorization bearer value, a full X-API-Key header, or a request to a non-Datadog endpoint — capture a sanitized screenshot showing:

  • The parameter / header name
  • The endpoint host
  • The timestamp

Then open a support ticket and attach these details. Credential exposure risk depends on the specific token type and endpoint, so any value other than the Datadog RUM client token will be assessed separately.

Tip: A full network capture (HAR file) can make analysis faster. See How to Generate a HAR File for Troubleshooting for step-by-step instructions, and remove any sensitive values before sharing.

Reference Documentation

Frequently Asked Questions

1. I see a "dd-api-key" value in my browser's developer tools. Is my account or data at risk?
No. In a Datadog RUM context, the dd-api-key value is a Datadog Browser RUM client token, which is intentionally visible client-side by design. It only associates submitted browser telemetry with a specific RUM application. It cannot be used to sign in, access application content, retrieve monitoring data, or change any Datadog configuration, so no data or account access risk arises from its visibility.
2. How can I tell the difference between a safe RUM client token and a real API credential that shouldn't be exposed?
A safe Browser RUM client token appears on requests going to Datadog RUM/session-replay telemetry endpoints (typically returning HTTP 202). A genuinely sensitive credential would instead appear as an Authorization: Bearer header, a full X-API-Key header, or on a request to a non-Datadog endpoint. If you observe any of those, capture a sanitized screenshot (parameter/header name, endpoint host, timestamp) and contact support for a separate assessment.
3. Do I need to rotate or hide this token to be secure?
No remediation is required for security purposes. Datadog does recommend managing client tokens through rotation and bot filtering, but this is only to reduce unwanted telemetry submissions (ingestion control). It does not change the fact that the token cannot access customer or administrative data.
4. Why does the application deliberately expose this token in the browser?
Browser-based diagnostics and session-replay telemetry run in the client, so the client token must be present in the browser to initialize and submit telemetry. Datadog explicitly distinguishes these client tokens from API keys and documents that client tokens are meant to be visible in browser applications, while API keys must never be exposed client-side.
5. I performed my own review and believe I saw something other than the Datadog token. What should I do?
Open a support ticket and attach a sanitized screenshot showing the parameter or header name, the endpoint host, and the timestamp. Because exposure risk depends on the specific token type and endpoint, any value other than the Datadog RUM client token will be assessed separately.
    Choose files or drag and drop files
Post
Was this article helpful?
Yes
No

Related articles