Client Token shown in plain text while using @datadog/browser-rum in our application

[Felistas]

The @datadog/browser-rum displays the client_token in plain text in the url. Shouldn't this be considered a secret or is this by design?

[BenoitZugmeyer]

No, the client token and application id are public data. Is it a concern for you?

[Felistas]

@BenoitZugmeyer was this by design? An attacker can get hold of the client token and send false information to our dashboard. I understand the client_token has only "write" access.

[BenoitZugmeyer]

This is by design, yes. This is similar to the Google Analytics "UA-XXXXX-Y" tracking id. Indeed, a malicious third party may use it to send false information, but the risk should be rather limited.

If you prefer not to disclose the client id, you can use the proxyHost option and store the client token in your backend. Note that it won't prevent malicious third parties to send fake data.

[Felistas]

Thanks for the clarification

[SenorMann]

Perhaps an option to whitelist domains in the RUM dashboard? @BenoitZugmeyer

[skandula106]

I guess datadog doesn't whitelist domains feature, it only whitelists IPs and whitelists domains are referring to email send /receive is it @BenoitZugmeyer

[skandula106]

Hi @BenoitZugmeyer we are using datadog for capturing user events but the client token was exposing via the browser of its nature how can we prevent this ?

[skandula106]

I saw in datadog docs can create a proxy server to prevent this, we created a proxy server and used allowedTracingUrls to add a security layer now also those keys will be available for network requests,

We need to configure domain level restriction in the datadog web level itself, earlier I worked Google Places library we purchased a key for organization use, keys are exposed in network requests of a browser nature but in the GCP we have an option to allow given domains only if the user copied that key he can't do anything because of domain level security configured in GCP.

Do we have like this in Datadog @BenoitZugmeyer?

[skandula106]

This is by design, yes. This is similar to the Google Analytics "UA-XXXXX-Y" tracking id. Indeed, a malicious third party may use it to send false information, but the risk should be rather limited.

If you prefer not to disclose the client id, you can use the proxyHost option and store the client token in your backend. Note that it won't prevent malicious third parties to send fake data.

We used a proxy host, but we must pass the client token in the datadog browser SDK init level itself, right? as per https://docs.datadoghq.com/logs/log_collection/javascript/#initialization-parameters @BenoitZugmeyer
and in the proxy level also those keys will be shown in the network tab but the datadog URL will be replaced with ours right?

One more thing we need to consider if we implement a proxy, we have an extra layer of data transfer will be added, which increases the performance because every client datadog network call will go to our proxy server and then to the data dog server,

here we need to whitelist the domain level itself in the datadog web interface do we have that @BenoitZugmeyer

[skandula106]

Any update on the request and this enhancement - #3236 @BenoitZugmeyer

[BenoitZugmeyer]

We used a proxy host, but we must pass the client token in the datadog browser SDK init level itself, right?

Not necessarily, you can pass any value (ex: clientToken: "replace-me") and then in the proxy you can replace it with the actual token (ex: url.replace("replace-me", clientToken)).

here we need to whitelist the domain level itself in the datadog web interface do we have that

No, we don't

Any update on the request and this enhancement - #3236

No update at this point, this is not something we are pursuing right now. I'll let your issue open for now to keep track of your request.