Open your admin dashboard, open devtools, and switch to the network tab. Sort by domain and count the hostnames that are not yours. On most panels built by a small team the number lands somewhere between three and eight, and at least one of those third parties is receiving a live reconstruction of whatever is currently rendered on screen.
What is rendered on screen, in an admin panel, is a customer record. A support ticket thread with someone’s complaint in it. A billing history. The user table, unfiltered, because an admin is allowed to see it. Session replay on a marketing site records a person browsing shoes. Session replay on an admin panel records your staff reading other people’s personal data, and forwards it to a vendor.
The mechanism has been documented for years. VPNpro research shows how widely session-replay scripts are deployed across sites that explicitly market themselves on privacy, and the VPNpro analysis draws on Princeton research finding that page content collected by third-party replay scripts can leak sensitive information displayed on the page, including medical records and credit card details, to the replay provider. That last detail is the one that matters for anyone building dashboards. These tools capture the DOM, not merely the inputs.
The masking gap that admin panels fall straight into
Every major replay vendor masks password fields by default. Most mask payment fields as well. That default was designed for a marketing-site threat model, where the sensitive data is whatever the visitor types into a form, and for that model it works reasonably well.
Admin panels invert the model. The sensitive data in a dashboard is not what your staff type in. It is what the application renders back to them: names inside table cells, addresses in a detail view, an email in a modal heading, a phone number in a tooltip. None of that lives in an <input>, which means none of it is covered by the default masking rules, and all of it leaves the browser intact.
What each category actually collects
| Script type | What it captures by default | The exposure inside an admin panel |
|---|---|---|
| Session replay | DOM mutations, clicks, scrolling, and user input events. | Every customer record, support ticket, and invoice visible on the screen can be captured. |
| Error tracker | Stack traces, breadcrumbs, and often request and response bodies. | API payloads containing user PII can end up attached to error reports. |
| Product analytics with autocapture | Every click, often using the clicked element’s text content as the event label. | Button labels are generally harmless, but table cell contents may expose sensitive data. |
| Tag manager | Any script that someone with container access chooses to publish. | An unreviewed script injection point inside a privileged admin interface. |
| Support chat widget | Page URL, page title, and in some configurations, visible DOM content. | Record IDs, customer names, and other sensitive information displayed in the interface. |
Locking it down
Mask at the element level rather than relying on input-type defaults. Every vendor supports this through a CSS class: .fs-mask, .logrocket-mask, .hotjar-mask, and their equivalents. Apply it in your shared table and detail-view components rather than field by field, because a field-by-field approach will miss something within a sprint or two.
Exclude the admin routes outright wherever the use case allows it. Most tools accept a URL exclusion list, and /admin/* has a strong claim to a place on it. If the team genuinely needs replay to debug an admin workflow, scope it to that one route rather than the whole panel.
Turn off request body capture in the error tracker. It is frequently enabled by default, and the scrubbing configuration is your responsibility rather than the vendor’s. An error report that includes the failing API request is enormously useful for debugging and enormously effective at exporting PII to a third party.
Set a Content Security Policy with an explicit connect-src allowlist. Of everything on this list, this is the only control that fails closed. It is what stops a script nobody approved from successfully phoning home, and OWASP maintains a detailed CSP cheat sheet worth working through properly rather than copying a permissive header from a Stack Overflow answer.
Review who can publish to the tag manager container. A marketing team member with publish rights to a container that loads on your admin routes has, in effect, arbitrary script execution inside your most privileged interface.
Start with the inventory
None of the above is actionable until somebody enumerates what is actually running. Open the network tab on the most sensitive screen in the dashboard, list every third-party domain receiving a request, and work through three questions for each: what does this script capture, is there a data processing agreement covering it, and how would we feel if this vendor were breached next month.
A template such as the Vue admin dashboards from CodedThemes arrives with none of these scripts attached, which means every one of them was added deliberately by someone on the team for a reason that was sound at the time. Analytics went in during the growth push. The error tracker went in after a bad release. The chat widget went in because support asked. Each decision was reasonable in isolation, and none of them were revisited once the panel started holding real customer records. That review is the work, and it takes an afternoon.
Comments