PII Redaction in Session Replay: Patterns That Work in Production

Session replay tools like rrweb do not record video — they serialize the DOM and stream its mutations so the session can be reconstructed pixel-for-pixel later. That fidelity is exactly what makes it a privacy hazard: everything the page renders is a candidate for capture. Input fields, a dashboard that prints the signed-in user's name and order history, a support widget showing an email thread, a token sitting in location.search — all of it is in the DOM, and a naive recorder will faithfully snapshot every character.

Network and console captures widen the blast radius further. A typical SaaS app logs the authenticated user's id and email on every request for debugging, and ships Authorization: Bearer eyJ... headers on each call. Per MDN, the Authorization header carries credentials directly (Basic auth is just base64-encoded user:password) — capture it verbatim and you have logged a live secret into your replay store.

GDPR Article 4 defines personal data as "any information relating to an identified or identifiable natural person." In replay context that spans the obvious (names, emails, government IDs, credit cards) and the context-dependent: a user id in a URL, an IP in a console.log, an order number that maps back to a customer. When in doubt, default-deny is safer than default-allow — treat unknown fields as sensitive until proven otherwise.

The mistake teams make is redacting only the obvious PII (the email input, the credit-card field) and missing the implicit PII bleeding through console logs, network payloads, OAuth tokens in URLs, and webhook bodies full of subscriber emails. Those surfaces leak more real PII than the form fields everyone remembers to mask.

The single most important decision is where redaction runs. Client-side redaction transforms the data inside the user's browser, before anything is buffered for upload — the approach BugMojo takes, and the one every privacy-first vendor converges on. PostHog states plainly that its privacy controls "run in the browser or mobile app, so masked data is never sent over the network." OpenReplay is equally explicit: obscured or ignored data "will never leave the user's browser."

Server-side redaction — upload everything, scrub it after it lands — is easier to build and lets you re-mask historical data retroactively, but it defeats the core privacy goal: the raw PII has already crossed your wire and sat, however briefly, in your infrastructure. If your ingestion tier is breached, client-side redaction protects you and server-side does not.

rrweb ships three distinct privacy mechanisms, and choosing the right one per element is what separates a usable redacted replay from a wall of grey boxes. Per the rrweb guide:

• Block — blockClass / blockSelector (default class .rr-block). The element is not recorded at all and is replaced with a same-size placeholder. Strongest, but you lose all context.
• Mask — maskTextClass / maskTextSelector and maskAllInputs (default class .rr-mask). The element is still recorded, but its text content and input values are replaced with masked characters, so layout and interactions stay intact.
• Ignore — ignoreClass / ignoreSelector (default class .rr-ignore). The element is recorded, but input value changes on it are dropped via the input handler.

The rule of thumb: mask by default, block only the truly sensitive. Masking a payment field keeps its red validation border visible so you can still debug the form; blocking it turns the whole region into a mystery box.

rrweb's built-in masking handles inputs cleanly. Set maskAllInputs to default-mask everything, then selectively allow the specific inputs you actually want to capture. Inputs are masked by default in modern versions precisely because they so often hold emails or passwords:

Inputs aren't the only PII source in the DOM. Marketing pages render the user's name in a greeting, dashboards show totals with card last-4s, support widgets surface email threads. A text-node regex sweep runs before serialization and replaces matched substrings with placeholders — the same pattern OpenReplay uses when it obscures emails inside text elements by default.

Console and network captures are the leakiest surface. Headers like Authorization, Cookie, X-Api-Key, and Set-Cookie should be dropped or hashed entirely. Bodies (JSON, form-data) should be regex-swept the same way text nodes are, and query strings should be sanitized because tokens routinely ride in URLs.

The regulatory case for client-side redaction is direct. The ICO's data-minimisation guidance (GDPR Article 5(1)(c)) requires personal data to be "adequate, relevant and limited to what is necessary," and warns you "must not collect or retain personal data on the off-chance that it might be useful in the future." A session replay that captures raw PII "just in case" is collecting more than it needs — the definition of a minimisation failure. Redacting at the source is how you demonstrate you only hold what the debugging purpose requires.

Card data carries its own regime. OWASP's Cryptographic Failures entry recommends you "don't store sensitive data unnecessarily" and, where you must, use PCI-DSS-compliant tokenization or truncation — store the last four digits plus a processor token, never the full PAN. The same logic maps onto replay: never let a full card number enter the recording, and Luhn-gate the fields where one might appear.

Consent is a separate requirement from masking, and it has three states: unset (first visit, recording disabled), granted (opted in, recording active), and denied (opted out, no further prompts). The state lives in chrome.storage.local for extensions or localStorage for in-page SDKs. Recording is gated on state === 'granted', and the dialog must appear before any capture data is buffered.

The dialog should disclose what's recorded (DOM, inputs masked, console, network with PII redacted), how long it's retained, who has access, and a link to the privacy policy. It must be dismissible without granting consent — the user must be able to say "no" in a single click, because implied consent by merely visiting the site is not consent under GDPR.

Redaction is a set of trade-offs, not a free win. Three honest caveats:

• Over-masking destroys debugging value. The whole reason to record sessions is to see what went wrong. Block too aggressively and you get a replay of grey rectangles that reproduces nothing. Prefer mask over block, keep non-sensitive UI visible, and resist the urge to blanket-block whole pages — a recording you can't learn from is as useless as no recording at all.
• Masking is not access control. Redaction limits what enters the recording; it says nothing about who can watch what got through. You still need authenticated, least-privilege access to replays, short retention windows, and audit logging on who viewed which session. A perfectly masked replay behind an open dashboard is still a breach waiting to happen.
• Client-side rules can't be changed retroactively. If a new PII field ships and your sweep didn't know about it, past recordings already captured it. Client-side redaction trades retroactive control for the guarantee that raw PII never left the browser — usually the right trade, but know you're making it.

• Async masking race. Input events fired before a mask propagated to the DOM, leaking 1–2 characters per keystroke for a ~50ms window. Solution: capture inputs synchronously in the rrweb event handler rather than relying on a downstream DOM mutation.
• False-positive credit-card matches. A 16-digit order number that happened to pass Luhn got redacted. Solution: combine Luhn with a context-aware filter (only match inside input values and known billing-field selectors).
• Compressed body leaks. gzip-compressed network bodies bypassed the regex sweep because we scanned before decompressing. Solution: decompress before redaction and recompress after, or filter on content type and skip capture of compressed payloads.

The fuzz test should also cover false-positive cases — a 16-digit order ID, an internal username containing an @, a UUID that looks like a JWT prefix. If those get redacted, developer experience suffers; if PII gets through, you have a breach. Track both error rates, not just the leak rate.

• Doing redaction server-side. Once data hits your wire, it has already been collected — at odds with data minimisation, and exposed if your backend is breached.
• No consent dialog. "Implied consent" by visiting the site is not GDPR consent.
• Forgetting query-string secrets. Tokens in URLs are PII too — sweep location.search and any captured URLs.
• Blocking when you could mask. Blanket blocking is the lazy default that silently kills your replays' debugging value.
• Trusting defaults blindly. maskAllInputs is on by default in modern rrweb, but text-node masking is not — you must opt in with maskTextSelector.

Start with the rrweb guide for the authoritative masking config, then compare how PostHog and OpenReplay expose the same block/mask/ignore ideas — cross-reading three implementations is the fastest way to internalise the model.

BugMojo runs PII redaction client-side, before capture data leaves the browser, on top of rrweb DOM recording (no video in V1) across its Chrome, Firefox, and Edge extension — so the console logs, network requests, and screenshots it captures for AI coding agents over MCP are scrubbed at the source, the way this article argues they should be.