The rise of third-party browser script attacks [Q&A]

Third-party browser scripts are the code snippets that organizations put into their websites to run ads, analytics, chatbots, etc -- essentially anything that isn't coded by the organization itself.

Which sounds innocuous enough, but these scripts are increasingly being used as a vector for cyberattacks. We spoke to Simon Wijckmans, CEO of c/side, to understand how these attacks operate and what can be done to defend against them.

BN: How significant a web security problem are third-party browser scripts? Are enterprises doing enough to secure this threat vector?

SW: Third-party browser scripts -- collectively, the browser supply chain -- remain an underappreciated web security threat. The lack of governance in using third-party scripts leads to data leaks, and most organizations lack sufficient visibility, protection and, frankly, knowledge.

Modern websites rely heavily on externally-loaded third-party scripts for functionality like analytics, chatbots, display ads, etc. User experience depends on these scripts -- they aren't going anywhere. But a vulnerability or compromise at any of these myriad (and sometimes even defunct) third-party providers can lead to widespread data breaches and security incidents when scripts get hijacked. Malicious scripts can skim sensitive information (unencrypted) directly from the user’s browser -- without their knowledge.

Despite major incidents like the British Airways breach, which exposed customers’ payment details, browser supply chain security hasn’t caught up. While IT security has seen more investment, the threat of malicious third-party scripts is minimized or addressed only through basic compliance requirements rather than specific defense measures. This is happening as browsers are become increasingly complex.

Legacy security processes and tools provide scant visibility into scripts executed within the browser -- a glaring gap in most companies’ security postures. Without monitoring all third-party script activity and content at runtime, enterprises remain dangerously exposed. This threat requires specialized detection and response capabilities that most organizations currently lack.

BN: British Airways became an early example of this kind of web attack. What lessons have been learned since that incident (and the major fines that followed)?

SW: The British Airways data breach was the first to really show the power of a hijacked script. A few things went wrong there but ultimately data was directly sent from the users' browsers to an attacker-owned endpoint -- for days until discovered. While similar attacks have followed, and recently incidents of data loss through site-wide implemented third-party scripts have emerged (look no further than the recent incident at US insurance giant Kaiser Permanente), the British Airways hack continues to offer up critical lessons, including:

• The need for comprehensive third-party script monitoring: most websites utilize 30+ third-party scripts that all had to be fully vetted and secured. Most companies cannot continuously monitor all these scripts at runtime and there is no clear governance, ownership, or point of contact for them.
• Legacy security is insufficient: Traditional security measures like network monitoring failed to detect the skimming attack because it originated from scripts executing within users’ browsers.
• Severe compliance penalties are possible: British Airways and Ticketmaster faced record GDPR fines (later reduced because of the pandemic).
• Reputational damage is very real: Beyond the financial penalties, brands took a significant hit that eroded consumer trust and spurred lawsuits.
• No company is too big to be vulnerable: One of the largest airlines, this attack showed that even major enterprises can be caught unprepared for this threat vector.

BN: What role does cybersecurity compliance play in securing third-party browser scripts?

SW: Compliance requirements -- particularly the updated PCI DSS 4.0 standard, are very relevant to the browser supply chain. The new PCI requirements explicitly mandate monitoring of any third-party scripts or code libraries that could potentially access payment data during digital transactions.

Previous versions of PCI did not provide such specific guidance around third-party script security. Risk went unaddressed within many companies. Under PCI DSS 4.0, companies handling payment card data will now undergo audits and assessments focused on their ability to continuously analyze the third-party script content being loaded and executed within their payment flows. Failure to implement rigorous controls and monitoring capabilities for third-party scripts in this context can and will result in businesses being found non-compliant with PCI DSS 4.0. This opens them up to potential fines, increased transaction fees from payment brands, and even the risk of having their ability to process card payments revoked entirely until remediations are made. Often cyber insurers require PCI DSS compliance in order to provide coverage.

Organizations must either dedicate skilled resources to build home-grown solutions for script monitoring and analysis or, more likely, adopt specialized third-party security tools specifically designed for comprehensive third-party browser script security and supply chain risk management. Maintaining PCI compliance has become a key driver forcing companies to get serious about this emerging attack vector.

BN: In the event of an attack on the browser supply chain, what steps should enterprises take once the breach is detected? How much damage can be mitigated?

SW: Teams need to act quickly. Any compromised third-party scripts or code libraries must be promptly blocked from loading and executing in the browser. This can be done by removing the script from the frontend code and updating Content Security Policy headers to prevent the malicious scripts from rendering. Any identified attacker-controlled domains utilized for data exfiltration should also be immediately flagged publicly.

Next, businesses need to transparently communicate the incident to impacted customers, partners, and any relevant regulatory bodies. Depending on the data exposed, this may involve notifying payment brands, privacy authorities, or other oversight entities per compliance requirements. From an investigation standpoint, analysis should try to understand the initially-compromised scripts, identify any additional scripts or code that may have been tampered with, and complete a full inventory of data potentially exfiltrated during the attack window. Incident response and digital forensics teams can work to contain and remediate the breach.

While these steps can prevent further data loss, any sensitive customer information already stolen is incredibly difficult to recover or mitigate the damage from. Identity theft, payment fraud, and regulatory penalties may be inevitable impacts depending on the breach’s severity. However, a rapid and coordinated response is critical for minimizing the overall customer impact and restoring security as quickly as possible across the browser supply chain.

BN: How do you see the landscape of these threats evolving in the next few years?

SW: The risk extends beyond third-party script hijacking. Insufficient governance leads developers to guess and implement scripts site-wide, including on pages with sensitive data. Over time, the original reasons why certain scripts exist fade (and new hires lack context). The philosophy of 'never change a running system' takes the upper hand.

Many script vendors are volatile, with frequent changes in ownership and business models potentially leading to data being sold. Modern web frameworks handle third-party scripts very poorly. For example: single page webapps allow scripts to persist from 'page' to 'page,' as the webpage does not actually re-render in the browser (instead, the framework re-renders the view using JavaScript). This can lead to script bloat and exposure of sensitive information.

Also critical to the conversation: browsers are becoming increasingly powerful. With technologies like IndexedDB, WASM, WebGPU, and Private Network Access, the attack surface has significantly increased. Browser engine providers are increasingly adding functionality, as there is constant demand for new and improved features in browsers. At the same time, more of our day-to-day experiences are happening in browsers, even when it isn’t clearly visible.

With the current scope of business and compliance, companies spend considerable time and effort covering their infrastructure and server-side behaviors from attacks. They store their data in ways that reduce incident scale if data leaks by hashing or encrypting their most sensitive data. Meanwhile, the browsers of users are the only place where a bad actor can easily access unencrypted sensitive data. However, due to the lack of pressure in existing compliance standards, this still has not been a focus for many.

The combination of evolving browser functionality, adoption of browser wrappers, frameworks handling third-party script risk in insecure ways, and companies' lack of compliance in companies make this an increasingly problematic space. We hope that PCI DSS compliance will help people understand the risk and prevent attacks where user data ends up in the wrong people's hands.

Image Credit: Solarseven / Dreamstime.com