PII scrubbing

Strip personal data at ingest. What never gets stored can't leak.

GlitchReplay applies two layers of PII scrubbing to every incoming event before it's written to D1 or R2:

  1. Built-in defaults — emails, credit-card-shaped numbers, AWS keys, JWT tokens, and the contents of Authorization headers and Cookie strings are redacted automatically. Always on, can't be turned off.
  2. Project rules — you can add custom field/regex rules per project that run after the defaults.

Replay recordings honor masking on the client side (maskAllText, etc.) — server-side rules don't apply to rrweb mutations because they're already redacted before they leave the browser.

Rule types

KindWhat it doesExample
Deny fieldReplace the value of a named field with [Filtered], anywhere it appears in the event tree.password, ssn, access_token
Deny regexMatch values against a regex; replace matches with [Filtered]./\b\d{3}-\d{2}-\d{4}\b/ for US SSNs
Allow fieldOverride a built-in default. Use sparingly — confirms you've read the trade-off.Allow email if your app legitimately needs the user's email in event context

Where rules apply

Rules run against every string value found in:

  • The exception message and stack frame variables.
  • Breadcrumb messages and data.
  • Request headers, query strings, and bodies (where present).
  • Tags and the extra object.
  • User context (user.id, user.email, etc.).

URLs are scrubbed at the query-string level — if a URL contains a matching token, the token is redacted but the path and host are kept.

Adding rules in the dashboard

Open Project → Settings → PII rules. Each rule has a kind, a value (field name or regex), and an enabled toggle. Rules apply on the next event — there's no need to redeploy.

Suggested starter ruleset for most apps:

  • Deny field: password, password_confirmation
  • Deny field: access_token, refresh_token, id_token, api_key
  • Deny field: credit_card, cvv
  • Deny regex: phone numbers in your formats (varies by region)

HIPAA / regulated workloads

On Business and Enterprise, GlitchReplay can sign a BAA. To stay aligned with HIPAA expectations:

  • Keep replay's maskAllText: true and maskAllInputs: true defaults. Don't opt elements into unmasked recording without an explicit reason.
  • Add deny-field rules for any PHI keys your app might pass to Sentry.setContext or setUser — patient IDs, MRNs, dates of birth.
  • Use the environment tag to separate PHI-handling environments and route their events to a separate project if you can. Less PHI in any one place is always better.

Verifying scrubbing works

After adding a rule, trigger a test event that should match it (e.g. throw new Error("ssn=123-45-6789")). Open the event in the dashboard — the matching substring should render as [Filtered]. If you can see the unscrubbed value, double-check the rule's kind and regex anchors.

What scrubbing doesn't protect against

Scrubbing only redacts values. The shape of the event — the keys, the URL paths, the stack-frame structure — is preserved. If a key name itself is sensitive (e.g. patient_diagnosis_code), rename the key before setExtra; scrubbing won't hide it.

Next: pull issues into your own systems with the REST API.