Third-party scripts are often deployed site-wide, typically injected in the head tags in web frameworks like Next.js via the ’_document.js’ file. This widespread implementation, while convenient for developers and often recommended by onboarding guides, means these scripts run across the entire site. This is simpler to implement, but it also introduces security risks and performance issues that are often overlooked.
The recent Kaiser Permanente data leak shows the dangers of having poorly managed third-party scripts. As we wrote in our full break down of the incident:
On April 29th, healthcare giant Kaiser Permanente disclosed a data leak impacting 13.4 million current and former insurance members. The incident was rooted in improperly managed 3rd party scripts.
Kaiser Permanente used tracking codes to monitor how its members navigated through its website and mobile applications. Some of these pages contained sensitive healthcare data, leading to the 3rd party scripts inadvertently transmitting information to third-party vendors they weren’t supposed to have.
While the breach wasn't a result of a script hijack, it highlights a significant oversight in handling third-party scripts.
But the issue is broader than leaking potentially sensitive information to third-party vendors. It reflects the issue of where third-party scripts are frequently used, but seldom examined or monitored. Even less so, secured.
The risks of deploying third-party scripts site-wide
Since we’ve covered the reasons why people often deploy scripts globally, let’s look at some of the issues they introduce.
1. Uncontrolled data access
This is what happened in the Kaiser Permanente issue. Third-party scripts often have access to sensitive data on web pages when deployed globally. This can include user inputs, session information, and other confidential data. Without strict controls, these scripts can inadvertently or maliciously leak data to unauthorized parties. In the case of Kaiser Permanente and other healthcare parties, the 3rd party scripts are often not Health Insurance Portability and Accountability Act (HIPAA) compliant, making a data leak to these vendors a serious incident.
2. Supply chain attacks
Attackers can compromise the web supply chain by targeting third-party services and injecting malicious code into scripts. These compromised scripts can then propagate malware, steal data, or perform other harmful actions on every site where they are deployed. This is bad as is, but even worse is when scripts are deployed globally and have access to more data and users.
Of course, c/side protects against this.
3. Single Page Web Applications (SPAs)
SPAs do not handle scripts well at all. Unless a developer performs a hard refresh upon navigating to a sensitive page, all previously loaded scripts remain present. Any third-party script loaded initially continues to run and potentially access sensitive data throughout the user's session, unless when a page gets hard refreshed, increasing the risk of data leaks and unauthorized access.
4. Compliance and Regulatory Risks
Organizations must comply with various data protection regulations such as GDPR, HIPAA, and PCI DSS 4.0. Inadequate management of third-party scripts can lead to non-compliance, resulting in hefty fines and legal repercussions.
With PCI DSS 4.0 requiring monitoring of third-party scripts by March 2025, the time is now to get started and put c/side in place. Not only does it make you compliant, it goes above and beyond by introducing autonomous blocking to protect yourself better.
5. Performance and Stability Issues
Perhaps less tricky but definitely noticeable, poorly optimized third-party scripts slow down websites. Any downtime or issues with the third-party service can directly impact the functionality and availability of the host website. A site that loads in 1 second has a 3x higher conversion rate as a site that takes 5 seconds to load.
Secure yourself against these issues
Just like the PCI DSS 4.0 guidelines, we're advocates for continuous security monitoring and encourage all site owners to adopt it. We believe that applying it to all pages is the most effective approach.
You can do this by using our free tier. It’s self-serve to get you compliant and safe within minutes. Of course we’re never far away to help out if needed.
Our script rewrites the sources of other scripts on your site to channel them through the c/side proxy. It also performs some browser-side detections. This allows c/side to mediate the request flow between the user and the third-party script without adding latency. In some cases, it can even enhance performance by caching static scripts.
This allows full insight into the scripts served, 100% of the sessions, and on all pages.
For more information on how our approach differs, read here.