Privacy-safe 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 withdefaultPrivacyLevel: 'allow'; - DOM text is masked during session replay;
- all input and
contenteditablevalues remain masked, including when visible page text is allowed.
Block or mask DOM content
The SDK recognizes privacy attributes without application-specific recorder code:Allow visible page text carefully
SetdefaultPrivacyLevel: '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
KeeptrackUrlQueryString: 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.
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.