Skip to main content
Apply privacy controls in the browser so sensitive values never reach the network. Start with the default masked mode and allow additional content only after reviewing the recorded result.

Privacy-safe defaults

With these defaults:
  • URL query strings and fragments are removed;
  • keys such as password, secret, token, authorization, cookie, api_key, and credit-card fields are recursively redacted from user, account, and context data;
  • action names are Click <structural selector>, and selectors carry no IDs, test IDs, or classes. The text of an element names an action only with defaultPrivacyLevel: 'allow';
  • DOM text is masked during session replay;
  • all input and contenteditable values remain masked, including when visible page text is allowed.
Field-name redaction is a safety net, not a data-classification system. Do not add credentials, payment data, health data, or unnecessary personal information to user or custom context objects.

Block or mask DOM content

The SDK recognizes privacy attributes without application-specific recorder code:
Replace the default selectors when needed:
Use blocking for secrets or large sensitive widgets, masking for text whose layout is useful, and ignoring for noisy elements that have no investigation value.

Allow visible page text carefully

Set defaultPrivacyLevel: 'allow' only after marking every sensitive region. Input values are still masked, and the configured maskTextSelector plus contenteditable elements remain masked.

Control URLs and network collection

Keep trackUrlQueryString: false unless the application guarantees that queries never contain identifiers or secrets. Exclude sensitive routes or network endpoints before collection:
allowedTracingUrls controls which origins can contribute trace context. The option does not enable request or response body capture; the SDK records timing and sanitized URL metadata.

Take sensitive text out at intake

The SDK is the first line of defense and the server is the second. An application takes the kinds of sensitive text it chooses out of every event before anything is stored, whatever SDK or client sent it. Open the application in RUM → Applications and turn the kinds of Sensitive data on or off. All of them are on for a new application. Text is taken out of the addresses an event was at and came from (view.url, view.referrer, resource.url, and the address of an error), the message and the stack of an error and its causes, the name of a view and of what was clicked, the GraphQL operation, payload, and variables of a request, the headers of a request and a response, and the context object. An address that appears inside text is scrubbed like an address, and the position a stack gives after it (:10:5) stays. user and account are what the application chose to send about a person, and are left as they are. Taking the text out happens before the event is made into rows, so what is derived from it is derived from what is kept: view.url_path and view.url_path_group of an address that held an email, and the issue an error belongs to. Errors that differ only in the email or the number in their message become one issue.
The kinds are shapes and checks, not a classification of data. A number that looks like a phone number, such as an 11-digit order number that begins with 13, is taken out as one, and a name or an address typed into free text is not recognized. Turn a kind off when it takes out what an investigation needs, and keep sensitive values out of events at the SDK.
A change applies to the events that arrive after it. What was stored before stays as it was. Session replay segments are not scrubbed: their text is masked by the SDK according to the privacy level above.

Review before production

1

Record a controlled test session

Exercise sign-in, checkout, profile, search, and error flows with non-production test data.
2

Inspect every event surface

Review session metadata, action names, URLs, error stacks, custom context, and DOM replay.
3

Add selectors and exclusions

Block sensitive subtrees and exclude routes that do not need collection.
4

Repeat after UI changes

Treat privacy selectors as production configuration and test selector behavior after markup changes.

Session replay

Configure DOM recording after defining the privacy boundary.
Last modified on October 26, 2026