Script Searched: How 2024’s Biggest Client-Side Attacks Left Millions of Websites ExposedScript Searched: How 2024’s Biggest Client-Side Attacks Left Millions of Websites Exposed

By Simon Wijckmans, CEO, c/side

In 2024, devastating client-side attacks ravaged the web, compromising millions of websites and exposing sensitive data at an unprecedented scale. From healthcare giants to tech industry leaders, these attacks didn’t just breach systems—they shattered trust, violated privacy regulations, and left countless users vulnerable. For security teams, the message is clear in 2025: Learn from these failures now, or risk becoming the next cautionary tale.

Here are five stories and lessons from the biggest and most eye-catching client-side web security incidents of the year. It’s time to wake up to the risk.

#1: Kaiser Permanente leaks sensitive patient health data to third-party vendors

This tale of poor client-side browser security actually doesn’t involve an attack, per se—although the harm done was just as bad. Kaiser Permanente is one of the largest healthcare providers in the U.S. In April 2024, the company disclosed that the third-party web script tracking codes (such as analytics tools and marketing pixels) it deployed to understand user behavior on its website and mobile app accidentally made that data available to third-party vendors. That meant 13.4 million customers had their on-site browsing behavior (and therefore their private health information) leaked to outside organizations.

Related:Data Privacy Quick Reference Guide

Many businesses’ marketing, data, and other departments direct engineering teams to implement third-party web scripts without any deliberate process in place to make sure that those scripts will continually keep data secure. This particular case also brings up the key issue of compliance: Kaiser is bound by HIPAA privacy regulations, making its failure to protect customer data subject to potentially massive penalties.

The lesson is that even large companies—with sizable security teams and resources—can mismanage third-party website scripts. Strategies going forward must go beyond content security policies and introduce capabilities that continually monitor the safety and compliance of third-party scripts, along with conditional rendering to control exactly which pages scripts load on.

#2: The Polyfill attack impacts half a million websites

Polyfill is an open source project and helpful third-party script that enables sites to utilize modern JavaScript capabilities in legacy browsers. While the solution is no longer necessary on most sites, the script is still widely present. Because the project dated back to 2014 and while webpages calling polyfill[.]io previously served a useful purpose, countless sites continued to do so even when the domain was purchased by malicious owners this year. What followed was a web supply chain attack that injected malware into half a million websites.

Related:Top 10 Cybersecurity Articles of 2024

The result: an altered JavaScript file injected by the domain redirected a fraction of users to adult and betting websites. However, those redirects may have been a tactic by attackers to cover up even more nefarious and harmful activity. The redirects occurred and gained attention only after attackers controlled the domain for six weeks, and it’s unclear what happened during that time. Hence, there is a need to monitor the client side. JavaScript attacks like this could easily include listening on keystrokes, mining cryptocurrency, page redirects to capture users’ credit card information, and more.

This attack was so high profile (and so inexcusable) that domain registrar Namecheap even took the domain down on their own behalf—a rare reaction that spoke to the severity of the situation. Google also stopped serving ads on the infected sites to protect users and ensure website owners noticed something was off.

If possible, companies that know a thing or two about security could self-host such scripts. That’s the most secure way—you have control, and no one can alter it (unless your infrastructure gets breached). This case demonstrates the dangers of allowing third-party scripts to run without active vetting and malicious code detection. Security teams should fully understand each and every script running on their web pages and remove unneeded scripts to harden the attack surface. That said, at the end of the day, protections that detect and block malicious scripts before they can harm will provide the most essential countermeasure against this kind of attack.

Related:The Impact and Future of AI in Financial Services

#3: Cisco falls victim to Magecart attack

Attacks on Magento e-commerce frameworks are prevalent enough to have earned the “Magecart attack” shorthand—describing third-party script attacks that introduce malicious code to capture website users’ personal data and payment information. This September 2024 case shows that even huge companies like Cisco can fall victim to these attacks. In this case, Cisco, own merchandise store running on Magento became a means of handling sensitive data to attackers. The incident also highlights the highly dynamic fly-by-night nature of attacker strategies, as the domain used in the attack was registered just a week prior.

Security teams should have monitoring and detection in place to recognize red flags. Examples are a week-old domain registry, ownership changes within companies supplying third-party scripts, altered code that adds unsuspected functionality, and other similarly suspicious activity.

#4: Kuwait e-commerce site used to facilitate client-side attacks

In another Magecart attack worth calling out specifically, malicious actors injected code and exposed customer payment data by compromising popular Kuwaiti e-commerce site Shrwaa[.]com. However, attackers didn’t stop there but instead began to use the site as a stepping stone providing the infrastructure to deliver further attacks. The site was made to host a list of malicious JavaScript files. Because of the domain’s established name (not known to be dangerous), those files could then be used to infect other sites without getting flagged as malicious. While this attack utilizing the site was recognized in October 2024, it likely began just before the start of the year and was active that whole time.

Since then, only three out of 94 threat feed vendors have flagged the domain as malicious—again illustrating the need for monitoring and detection tools.

#5: Artifyau[.]com and Quantifymy[.]com use polyglot documents to disguise malicious third-party scripts

This attack discovered in November 2024 uses a clever technique involving a polyglot document, or a file valid as multiple file types, such as HTML and JavaScript. In this case, an injected script tag loads a polyglot document that renders an acceptable-looking “service unavailable” page when browsed as HTML, but malicious JavaScript when injected into a site.

This attack also plays some of the greatest hits, with it being another Magecart attack, and the Artifyau[.]com domain having been registered just in mid-October trying to fly below the radar. Defense strategies that can pass scripts through a safe proxy environment to test and expose malicious payloads where they can’t cause problems will provide essential protection against this attack strategy and others.

The Client-Side Security Space Needs Urgent Attention

As these attacks make clear, attackers have a range of approaches and creative tactics when ushering their exploits from that first code injection to a full data breach. JavaScript-based attacks leveraging third-party scripts are plentiful and on the rise.

The Polyfill attack alone put as many as half a million sites at risk, with the total impact and exposure of users’ private information still unknown, let alone all the other attacks that have been, and are, active without anyone knowing it. At the same time, three out of every four Adobe Commerce and Magento sites were open to attack this year (adding up to hundreds of thousands of sites more), thanks to CosmicSting and other browser supply chain vulnerabilities.

PCI DSS v4.0.1 is a crucial and particularly timely variable, with the new requirements coming in that call for extra security on third-party web scripts. By March 2025, websites need monitoring, integrity checking, and regular checking of third-party scripts on payment pages. For full protection, all pages should follow these principles.

By learning the lessons these stories offer, security teams can implement the protections to see those attacks coming from the beginning and better ensure the safety of their website users going into 2025.

About the Author

Simon Wijckmans is the CEO and founder of c/side, a cybersecurity company focused on browser-side threat detection and protection. Previously, he held product management roles at Cloudflare and Vercel.