A recent report by The Markup, validated by research published in Patterns, highlights the risk of including third-party JavaScript in an organization’s website. The studies discovered that the Meta/Facebook “pixel” that was included on a large number of hospital and health organization websites was sending sensitive medical data to Meta, possibly in violation of HIPAA regulations.
Given the way the modern web is constructed, with pages assembled in real-time in the customer’s browser, there is an increasing risk across all sectors that some third-party JavaScript does more than you think. This could be due to many reasons, including a misunderstanding of a script’s capabilities, a developer error, or malicious tampering by a threat actor.
We’re past the point of changing the way that the web works — it is not uncommon for sites to load more than 35 scripts, with over 70% coming from third-party domains. From an information security perspective, we have to acknowledge that what is loaded in the consumer browser is now a team activity, in partnership with our digital marketing colleagues.
However, we have an obligation to manage the risk of data leakage and other JavaScript attacks (such as in-page crypto miners) to protect our customers and our organizations. This is especially true if we have to comply with external regulations and standards such as HIPAA or PCI DSS.
This requires three capabilities: observability, risk management and control.
Observability: What JavaScript is being loaded into our customers’ browsers as they use our websites and web apps, and more importantly, what is that JavaScript doing?
Risk management: Understanding the inherent risk associated with a script and taking the appropriate action. Is it a script that’s known and has been seen many times? Is it novel? What domains is it associated with? Did it recently change? What are its behaviors — is it reading fields, modifying the page’s domain object model, or transmitting data?
Control: There are some third-party JavaScript behaviors that should always be prohibited in certain areas of the website — for example, reading the data from form fields and sending sensitive personal or payment data to external hosts in potential violation of GDPR, CCPA, and PCI DSS regulations. These should be blocked by default so a script exhibiting rogue behavior is automatically blocked, after which it can be investigated and analyzed.
To protect their customers’ privacy and their own infrastructure, organizations should continuously monitor site content, identify and analyze the behavior of new scripts, and make informed decisions about whether or not to block them. Website designers should incorporate granular controls over sections of a webpage that collect sensitive customer data, blocking
all unwanted activity such as reading form fields and exfiltrating data.
About John Elliot
John Elliott specializes in regulated security and data protection. He’s represented both Visa Europe and Mastercard on the PCI Security Standards Council and contributed to many of the PCI standards including most recently PCI DSS v4. John has led aviation and financial services InfoSec and data protection functions and has recently embraced the role of Security Advisor at Jscrambler.
