fix(webapp): keep PHI out of PostHog and Sentry - #6906
Open
macko911 wants to merge 5 commits into
Open
Conversation
Customer-supplied data rendered in the dashboard (records, logs, connection metadata) can contain PHI and must not reach telemetry subprocessors (NAN-6428): - Mask all rendered text in PostHog session recordings and autocapture by default; static Nango-owned chrome can opt out via data-ph-unmask. - Remove Sentry session replays entirely. - Drop console breadcrumbs and strip serialized non-Error throw payloads from Sentry events; SWRError is now a real Error subclass so response bodies stay out of error reports. - Redact customer-chosen connection ids from URLs captured by both tools.
Contributor
Preview Deploy
|
Contributor
There was a problem hiding this comment.
All reported issues were addressed across 6 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Session recordings capture network entries whose urls include /api/v1/connections/<id>; run them through the same redaction as event urls so recordings can keep network timing enabled.
Navigation breadcrumbs carry urls in data.from/data.to, not data.url. rrweb matches maskTextSelector against ancestors, so the :not() opt-out never applied; mask everything and unmask via maskTextFn.
Connection ids are UUID4-generated for years and customers are required to keep PHI out of custom ids, so redacting them from PostHog/Sentry urls adds moving parts without a real risk behind it. Masking, replay removal and error-payload fixes stay.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The dashboard renders customer-supplied data (records, logs, connection metadata, action outputs) that can contain PHI, and our frontend telemetry captures some of it: PostHog session recordings only mask inputs (rendered text is recorded), Sentry runs session replays in prod, and the SWR fetcher throws the full API response body, which Sentry serializes into error events. If PostHog or Sentry receive PHI they become PHI subprocessors and we'd need BAAs with both.
Solution
maskTextSelector: '*'+maskTextFn) and autocapture (mask_all_text,mask_all_element_attributes) by default, so new UI can't leak by accident; static Nango-owned chrome opts out viadata-ph-unmask(applied to sidebar nav labels).replayIntegration()entirely; drop console breadcrumbs; strip serialized non-Error throw payloads viabeforeSend; pinsendDefaultPii: false.SWRErroris now a realErrorsubclass (samejson/statusfields, all consumers unchanged), so Sentry only sees name/message/stack instead of the response body.Connection ids are deliberately not scrubbed from captured URLs: Nango has generated UUID4 ids for years, and customers are required to keep PHI out of custom ids.
Fixes NAN-6428
Testing
Replay, and aconsole.logwith a canary string produced zero console breadcrumbs while fetch/nav/click breadcrumbs flowed normally.data-ph-unmaskopt-out) will be validated end-to-end with a sentinel sweep after deploy, per the ticket.