The cybersecurity industry has been focused primarily on the server side of web applications, and not on the client (browser) side at runtime. As Kamal Govindaswamy CISSP, CCSP and Sergei Vasilevsky, CISSP explain why exploitation at run-time in consumer web browsers is a significant concern in today’s web-centric world.

Kamal Govindaswamy CISSP, CCSP and Sergei Vasilevsky, CISSPRecent times have seen increases in cybersecurity breaches, data leaks and supply chain attacks, all associated with compromises beginning at runtime on users’ internet browsers. Here, traditional data center cybersecurity solutions lack the visibility and reach to detect, protect and respond to such incidents.

The recent Polyfill.io supply chain attack is just the latest such incident involving exploitation at run-time in consumer web browsers. Starting with the Magecart-style attacks, focused on skimming payment card data at prominent organizations including British Airways and Ticketmaster among many others, these attacks have resulted in a variety of compromises such as stealing payment card data and unauthorized access or transfer to personal data protected by privacy regulations. The recent cases at Kaiser Permanente and the U.S. Department of Education are examples of several cases that resulted in the compromise of sensitive personal data by transmitting them to third-parties in an unauthorized fashion.

Evolving Web Application Threats

Web application security is not a new discipline in cybersecurity. The fact that the OWASP Top 10, the premier web application security awareness project, is more than 20 years old shows that we have been focused on web application security since long before many of the modern web application threats were known or anticipated.

For much of this time, however, the cybersecurity industry has been focused primarily on the server side of web applications, and not on the client (browser) side at runtime. More recently, it has become clear that much modern web application code is hosted and served dynamically at runtime from digital supply chain partners and open-source code repositories, introducing new third-party risks. Dynamically loaded third-party code may in turn rely on a cascading set of other third-parties and code repositories. It's not uncommon for once-popular open-source projects to become neglected, leaving vast portions of the internet vulnerable to attack. Malicious actors only need to compromise one widely used library to potentially gain access to numerous web applications and to confidential data from any organization that operates them.

Coining the Term: Web Client Runtime Security

Our experience with Web Client Runtime Security (WCRS) started while conducting PCI DSS 4.0 readiness engagements - specifically while advising our healthcare clients in the context of recent guidance on tracking technologies issued by the US Department of Health and Human Services, Office of Civil Rights and the U.S. Federal Trade Commission.

As we worked to achieve compliance with new PCI DSS eSkimming detection requirements, we studied several breaches that underscored the need for client-side security well beyond that used in the payment card industry. While server-side security often gets the most attention, it became clear to us WCRS is often overlooked.

At the same time, we engaged with startups and established vendors in the security space. They frequently referred to their solutions as addressing "client-side security," a term we found ambiguous. WCRS better articulates the specific nature of the challenges we were tackling – particularly the real-time risks involving web clients (browsers) and server interactions.

Our Approach to WCRS

During our engagements, we discovered that many organizations were either unaware of the security risks posed by third-party scripts or lacked the means to mitigate them effectively.

Our work in this area began with identifying which of their web applications fell within the scope of PCI DSS compliance. Many of these applications interacted with external services, and the use of client-side scripts from third parties created potential vulnerabilities that had gone unnoticed.

Once we had identified the applications in question, we conducted a detailed inventory of the scripts running on the web clients. This involved analyzing each script – whether custom-built, open source, or provided by a third party – to assess its behavior and infer its intended purpose. The results were often surprising: many scripts were outdated or no longer relevant, while others introduced unnecessary risk by connecting to external services that were poorly maintained.

We would then highlight scripts that were redundant, outdated, or potentially dangerous for an organization. Our goal with this part of the process was to foster a collaborative discussion that empowered organizations to make informed decisions about which scripts were essential and which could be safely removed or replaced. Through the review, organizations gained a deeper understanding of their dependencies as well as the risks they carried.

Finally, and to help them secure their web applications moving forward, we assisted organizations in developing vendor selection criteria for WCRS solutions. With the right security vendors, they could ensure ongoing real-time monitoring of their web clients, helping them mitigate risks associated with third-party scripts and maintain compliance with industry standards.

Key Lessons in WCRS

Over the course of these engagements, we encountered several critical issues that revealed just how vulnerable many web applications are to client-side security breaches.

One of the most important lessons came from the Polyfill.io attack. Polyfill.io, a service used by developers to ensure compatibility across different web browsers, became a major point of exposure for one organization we worked with. They were relying on Polyfill.io even though it no longer served a critical function. Once the attack happened, our technical assessment quickly identified this dependency, and we helped to remove it, significantly reducing the organization’s exposure.

Another common issue was the presence of dead script links – scripts that connect to resources or services that were no longer maintained or secure. Like the Polyfill.io example, these links posed serious risks because they could be targeted by attackers. By helping to identify and remove these outdated dependencies, we were able to close potential loopholes and improve overall security posture.

Additionally, we found that many organizations were relying on multiple third-party scripts with overlapping functionality. This created unnecessary complexity, as well as additional points of vulnerability. By identifying opportunities to consolidate these scripts, we were able to streamline operations, reduce attack surfaces and improve performance in the process. The value of reducing third-party script dependencies cannot be overstated: fewer scripts mean fewer opportunities for exploitation.

The Importance of WCRS

The challenges we encountered during these PCI DSS 4.0 engagements revealed the growing importance of WCRS. As web applications become more complex and increasingly dependent on third-party services, the risks associated with client-side scripts continue to grow. The combination of third-party scripts, legacy dependencies, and real-time interactions between web clients and servers creates a fertile ground for attackers.

Incidents like Polyfill.io highlight the need for proactive measures. More than ever, organizations must be vigilant about the security of their client-side scripts. We anticipate that more vendors will emerge to meet the increasing demand for real-time client-side security solutions and it will be essential to choose the right partners to help organizations protect their digital assets.

As this space evolves, it will become increasingly clear that WCRS is not just a niche concern but a new reality of the evolving threat landscape. The stakes are high but, with the right approach, security leaders can navigate these challenges and stay ahead of evolving risks.

Kamal Govindaswamy, CISSP, CCSP has over 20 years of consulting experience in strategy, design and implementation across IAM, data security, logging and monitoring, GRC and third-party risk management. His experience spans multiple industries, including healthcare and financial services.

Sergei Vasilevsky, CISSP has over 20 years of experience in cybersecurity, risk management, and compliance. He has held technical and management roles, with responsibility for developing and implementing cybersecurity architecture, IAM and GRC solutions. Sergei’s work spans multiple industries, including finance, healthcare and aviation.