by Source Defense
A Lesson in 3rd Party Risk on the Modern Website
TL:DR – You Cannot Protect Data You Do Not Control
If you’re engaged in electronic commerce, PCI DSS has taught you over the past couple of years that you need to control all of the 3rd party scripts running on your website. The broader world needs to take note and get serious about this major gap in web security and data privacy – and last week served up just another example of why.
When news broke last week that an attacker accessed analytics data inside Mixpanel’s systems and pulled personally identifiable information linked to OpenAI’s customers, many people had the same question: who is Mixpanel and why did they have this data in the first place?
Mixpanel is a popular product analytics platform. Companies embed the Mixpanel script in their websites and applications to measure user behavior, track feature usage and understand how people move through a digital experience. It is a standard tool in modern software teams. It is meant to collect trends and events, not personally identifiable information. Yet in this incident, Mixpanel ended up with user names, emails, approximate locations, device details, referring URLs and internal account identifiers for OpenAI’s API customers.
This is the underlying problem. Once a script is on your site, it has as much access as the page gives it. If it is not controlled or scoped, it can see far more than intended. In Mixpanel’s case, that extra visibility turned a simple analytics integration into a breach that exposed data belonging to real users.
Analytics Tools Should Not Have PII – But they DO!
Analytics platforms do not need names or email addresses to report trends. They do not need to read form fields to understand user flow. Yet many analytics scripts can access those inputs by default because most organizations never limit them.
A script placed on the page can pick up data through URLs, form submissions, dynamic content and session variables without anyone realizing it. Even if the business does not intend to send identifiable information to a vendor, scripts often collect it through side channels. If that vendor is later breached, all of that information becomes part of the incident.
This is not new. We have seen health care systems accidentally share protected health information through misconfigured Meta Pixels. Retailers have leaked account details through Google Analytics. Tag managers have pulled sensitive information without anyone on the security team noticing. None of these cases involved malicious code. They were ordinary scripts with excessive access.
3rd Party Script Management – It Is Not Just eSkimming, PCI DSS and Payment Data…It is about Data Privacy TOO!
One reason the Mixpanel incident stands out is that it did not involve payment information at all. It still posed a real privacy and business risk for OpenAI’s customers.
That is the point. Sensitive data is not limited to cardholder information. Modern sites collect far more across the entire digital experience. This includes user identities, contact information, authentication details, behavioral data and other fields that are valuable to attackers and regulated by privacy laws.
Every time a 3rd party partner script loads in the browser, it becomes a potential collection point. A breach at that partner becomes your problem. It does not matter which page the data came from or whether payment was involved. The risk applies everywhere.
Zero Trust for Third Party Partners
Most companies treat analytics and marketing scripts as harmless. They focus on their own application security and assume their partners do the same. That assumption is what puts data at risk.
A mature Zero Trust model applies to third party JavaScript as much as it applies to internal systems. Scripts should never have open access to the page. They should operate within strict controls that define what they are allowed to read, what they can modify and what they are permitted to send outside the domain.
Without those guardrails, every script becomes a single point of failure. If the vendor is breached, you have no control over what data was exposed or how it was used.
How Source Defense Helps
Source Defense was built to solve this problem. We give organizations full visibility and control over every script that runs in the browser. We enforce least privilege, so analytics tools like Mixpanel cannot access sensitive inputs. We block unwanted behavior in real time. And we update protections the moment an issue emerges.
For customers using our recommended Mixpanel policy, no PCI related data could ever reach the vendor. After OpenAI published its disclosure, we updated the default Mixpanel policy to further tighten what the script can access. That is the strength of behavior based controls. They adjust instantly without requiring code changes or long remediation cycles.
Customers can review Mixpanel’s activity directly in the platform and confirm exactly what the script has done on each site. If anything unusual appears, our team reaches out.
This type of oversight should be standard across every digital property. It is not enough to protect payment pages. You must protect every page and control every script that has the potential to interact with or handle data worth stealing.
The Time for Control Has Passed
The Mixpanel breach is not an isolated event. It is part of a larger pattern across industries. Organizations add third party scripts faster than they can audit them. Most of those scripts run with broad permissions. And none of them are treated with the caution they deserve.
If you want to understand how these partners behave on your site or want support reviewing your own exposure, our team can help.
Your site already depends on third party code. The real question is whether that code is working within your rules or outside them.
Request a demo or talk with our team today.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.