Browse docs
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:
- Built-in defaults — emails, credit-card-shaped numbers, AWS keys, JWT tokens, and the contents of
Authorizationheaders andCookiestrings are redacted automatically. Always on, can't be turned off. - 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
| Kind | What it does | Example |
|---|---|---|
| Deny field | Replace the value of a named field with [Filtered], anywhere it appears in the event tree. | password, ssn, access_token |
| Deny regex | Match values against a regex; replace matches with [Filtered]. | /\b\d{3}-\d{2}-\d{4}\b/ for US SSNs |
| Allow field | Override 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
messageand stack frame variables. - Breadcrumb messages and data.
- Request headers, query strings, and bodies (where present).
- Tags and the
extraobject. - 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: trueandmaskAllInputs: truedefaults. 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.setContextorsetUser— patient IDs, MRNs, dates of birth. - Use the
environmenttag 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.