A support vendor's chat and session-replay script runs on your logged-in pages — what data actually leaves your boundary?

## Why this integration is different from an API integration Most vendor integrations are server-to-server: you decide the fields, you build the request, and the diagram shows one flow with a known payload. A widget delivered as a script tag inverts that. You are not sending the vendor data; you are inviting the vendor's code into the page where your customer is authenticated, and it decides what to collect. On a data-flow diagram the honest depiction is not one labelled arrow — it is a process you do not control, running inside the client, with a flow out of it whose contents you have not enumerated. ## What "first-party inclusion" actually grants A script loaded into your page's origin can, by design of the web platform: - read and modify the entire DOM, including values rendered into forms and pages; - observe keystrokes, clicks, focus and form input as the customer types; - read storage and any token the page keeps where script can reach it; - issue requests as the page, and change what the page displays. Session replay makes deliberate use of most of that: reconstructing a session means capturing the DOM and the input stream. So the capability you granted and the capability the product needs are close to identical, which is why "we only use it for support" is not a boundary — it is a usage intention on top of an unrestricted grant. ## The two flows worth drawing **Flow one: browser to vendor.** Content is whatever the page held. On a settings or checkout page that includes address, payment fields, and sometimes values that were never meant to leave, such as an identifier a customer pasted in. Modeling it as "session metadata" is where teams go wrong. **Flow two: vendor store to vendor staff.** The replay is not just stored, it is *watchable*, and typically by any agent in the vendor's console. A threat model that stops at "the vendor holds the data" misses that the practical adversary here is often a single rogue or socially engineered agent, not a breach of the vendor. Ask who at the vendor can open a replay of an arbitrary customer, whether that access is per-agent identified, and whether it is logged in a way you can ever review. ## Threat categories in play - **Information disclosure**: the headline. Customer data and any credential-like material visible in the page cross a boundary continuously, at the volume of your traffic. - **Tampering**: the script can alter the rendered page. A compromised vendor script can change displayed values, inject fields, or silently modify a form before submission. - **Spoofing / credential capture**: input capture on an authenticated page reaches passwords typed into re-authentication prompts and one-time codes, which is a path to account takeover rather than mere data leakage. - **Elevation of privilege**: not in your servers, but inside the customer's session, which is the privilege that matters to them. ## The same pattern, a different vendor The managed observability vendor is this problem with the arrow pointing out of the backend instead of the browser. Nobody decided to send request bodies and authorization headers to a third party; the logging call sites simply dumped what they had, and the pipeline forwarded it. In both cases the defining property is the same: **data leaves your boundary because of how a mechanism works, not because anyone specified that flow.** That is the class of threat this leaf exists to make you look for — and the question to ask of any vendor integration is not only "what did we agree to send?" but "what does this mechanism carry by default?" ## Controls that follow from the model - **Placement.** Do not load a DOM-reading vendor script on authentication, payment or account-settings pages. This costs product capability and is usually the single largest risk reduction available. - **Deny by default at capture.** Configure the capture to record nothing sensitive unless explicitly allowed, rather than masking a list of known-bad selectors. Understand that this configuration runs inside a page the vendor's code also controls, so it reduces accidental collection well and reduces deliberate collection much less. - **Isolate where the feature allows.** If the vendor supports rendering in an iframe on their own origin, the same-origin policy removes their DOM access outright, and the flow becomes only what you explicitly send in. Many chat products work this way; replay products generally cannot, which is itself a useful signal about the trust each one requires. - **Constrain the reader set.** Require per-agent identity, need-based access to replays, retention limits, and access logs you can request. - **Content controls on your side.** Keep tokens out of DOM-reachable places, and stop rendering full values you do not need on screen. ## The answer that lands in an interview State the grant plainly — first-party script means full access to the authenticated page — then name both flows, then explain that the compromised or rogue-agent case is the *modeled* threat rather than a footnote. Finish on the control that a strong candidate reaches for first: not a longer masking list, but keeping the vendor's code off the pages where the value is.