Introduction
Web client runtime security (WCRS) refers to the security or behavior of the code executed in users' internet browsers during their web interactions. The first part of this article series includes details of why WCRS as a security discipline warrants specific focus in addition to traditional web application security practices. Traditional approaches to web application security have often focused on scanning code for vulnerabilities, as well as scanning and monitoring for security weaknesses from the perspective of the web hosting provider.
This second article describes the limitations of traditional security solutions in addressing WCRS risk and proposes implementation options for purpose-built security solutions. Specifically, the strengths and limitations of three key traditional application security mechanisms are covered, before proposing certain viable implementation options for addressing WCRS needs. These mechanisms include static analysis, dynamic analysis, and manual code reviews, each offering unique benefits and challenges in the context of web application security.
Static Application Security Testing
Static application security testing (SAST)1 involves analyzing source code for vulnerabilities while the application is being developed or analyzing any code changes that are made to an existing application. This is a traditional approach to code scanning that is utilized by many organizations. SAST can catch many vulnerabilities before applications are released into production. Some vendor products generate a report of potential vulnerabilities. Others go a step further, by scanning code while a developer is typing, and highlighting potential problems in the integrated development environment. After reviewing the vulnerability report produced by one of these tools, developers might go through multiple code remediation and re-scanning cycles until a passing scan is achieved. This approach is beneficial for early vulnerability detection, allowing developers to address issues before the code is deployed. Figure 1 summarizes the pros and cons of SAST.
Figure 1 — Static Application Security Testing (SAST) Considerations
However, SAST does not account for runtime behaviors or interactions with dynamically loaded scripts, which are common in modern web applications. As a result, vulnerabilities introduced through third-party scripts or supply chain attacks can go undetected. SAST tools are designed to assess code as it is written, not as it is executed in the varied web application environments, limiting their effectiveness in addressing WCRS threats.
Strengths—SAST analyzes source code for vulnerabilities, offering early detection during the development phase.
Limitations—SAST does not cover runtime behaviors or interactions with dynamically loaded scripts. It may also not detect vulnerabilities introduced through third-party scripts or supply chain attacks.
Dynamic Application Security Testing
Dynamic application security testing (DAST)2 involves testing applications in their running state and simulating real-world attacks to identify vulnerabilities. This method provides insights into application behavior while under attack and can uncover issues that static analysis might miss. Many organizations supplement their SAST processes with DAST because DAST scans can detect vulnerabilities in the deployed environment, which would not be evident from reviewing application code. Server misconfigurations, weak authentication, and security headers are some examples of vulnerabilities detected by DAST scans. The pros and cons of DAST are depicted in figure 2.
Figure 2 — Dynamic Application Security Testing (DAST) Considerations
DAST has its limitations, particularly in detecting vulnerabilities that manifest only in specific web client runtime environments. Malicious code can evade DAST by activating only under certain conditions that the testing environment does not replicate. Additionally, DAST cannot fully understand and evaluate the behavior of third-party scripts, rendering it less effective against the threats that exploit these external dependencies. Last, DAST scans are detective by nature, offering few preventive capabilities that would protect organizations during supply chain attacks at runtime.
Strengths—DAST tests applications in their running state, simulating real-world attacks.
Limitations—DAST might miss vulnerabilities that only manifest in specific web client runtime environments. Malicious code can hide from DAST by only executing in specific user contexts, and DAST does not provide real-time protection from unwanted script behavior.
Interactive Application Security Testing
Interactive application security testing (IAST)3 combines elements of SAST and DAST by analyzing applications in real time during normal operations. This method allows for more comprehensive detection of vulnerabilities by observing code execution and interactions from within the application, as opposed to external DAST scanning. It enables organizations to detect issues that may go unnoticed by SAST or DAST, such as vulnerabilities arising from specific application workflows or interactions between components. Figure 3 depicts relevant IAST considerations for organizations.
Figure 3 — Interactive Application Security Testing (IAST) Consideration
While IAST provides deeper insights compared to purely static or dynamic testing, it still faces challenges in WCRS. IAST tools require integration into the application, which can be complex and resource intensive. Moreover, they may not fully capture the behavior of third-party scripts or adequately monitor client-side code that executes in user browsers, limiting their effectiveness in preventing client-side attacks.
Strengths—IAST combines elements of SAST and DAST by analyzing applications in real time during normal operations.
Limitations—IAST tools require integration into the application, which can be complex and may not detect client-side script vulnerabilities introduced by third parties.
Traditional Security Mechanisms are Limited
SAST, DAST, IAST, and other traditional security tools, such as firewalls, intrusion detection systems, and endpoint detection and response (EDR) systems are limited by their perspective of application and infrastructure runtime states from a provider’s point of view. They might inspect the observable network traffic between client web browsers and the trusted private hosting environment where much of the web application content might be hosted. However, these tools may overlook unintentional data leaks between client browsers and third-party services, as well as Magecart attacks that could exploit these trusted third-party services. The gaps in coverage of the traditional security tools are illustrated as potential risk in figure 4.
Figure 4 — WCRS Limitations of Traditional Security Solutions
These limitations underscore the need for specialized client-side security solutions. Such specialized solutions should examine runtime states from a client’s perspective and address the unique challenges of securing client-side code.
Technology Solutions for WCRS
As traditional application security mechanisms or approaches do not provide necessary safeguards against WCRS risk, organizations may need to consider other options for their WCRS capabilities. This section proposes certain mechanisms, each of which may have distinct approaches and corresponding benefits.
The web client-side security market has witnessed significant growth in recent years, driven by the increasing recognition of the risk associated with third-party scripts and supply chain attacks. This rapidly maturing space features a variety of solutions, each with distinct approaches and benefits.
Organizations should evaluate each approach carefully before selecting the most suitable options for their specific website contexts.
CDN and Proxy-Based Solutions
Many internet-facing web applications are already deployed behind content delivery networks (CDNs) to protect them from distributed denial of service (DDoS) attacks and improve performance by caching content closer to end users. Given their strategic position in the delivery chain, CDN providers are well-suited to enhance client-side security by examining all resources before they reach client browsers. By intercepting and analyzing web traffic, CDNs can identify and block malicious scripts, ensuring that only safe and verified content is delivered.
CDN and proxy-based solutions offer a transparent layer of security without requiring significant changes to existing infrastructure. This transparency is a major advantage, as it simplifies deployment and reduces the burden on development and operations teams.
These solutions typically feature a web-based portal that offers near real-time visibility into the resources loaded by clients. Through this portal, customers can monitor scripts and other elements being delivered to end users.
Strengths— CDN and proxy-based solutions require minimal effort for the initial deployment if monitored web applications are already protected by the CDN solution from DDoS attacks. In such cases, the CDN provider is already able to monitor web traffic, and the client security module is simply enabled by the third-party CDN provider upon purchase. This solution also avoids the introduction of third-party code into web applications, often shortening implementation timelines and avoiding delays due to vetting by other cybersecurity and third-party risk teams within the purchasing organization.
Limitations—Visibility of third-party script behavior is limited to data transmitted via the CDN network and is not always representative of third-party script behavior on customer browsers, particularly once they begin interacting with the web application. Furthermore, this solution is only offered by a limited number of CDN providers. Internally facing applications, including traffic that is not routed through a particular CDN, would require a different approach for client-side protection.
Remote Scanning Solutions
Remote scanning solutions provide an external perspective on the security of web applications by assessing them from outside the organization’s network. These tools are designed to identify vulnerabilities and malicious code that may be present in the client-side scripts and resources delivered to users. By periodically loading and crawling an internet-facing web application, remote scanners can detect and analyze scripts, security headers, and other resources that would be loaded by client browsers while interacting with a monitored web application, offering a simplified view with minimal effort from customers.
One of the primary benefits of remote scanning is its ease of implementation. Since these tools operate externally, they require minimal configuration and do not require updates to the existing infrastructure or code. Remote scanning can quickly provide a high-level overview of the security posture of web applications, highlighting areas of concern that require further investigation. However, while remote scanning is effective at identifying many common vulnerabilities, it has its limitations. For example, it may struggle to access and analyze content behind authentication barriers, and sophisticated malicious code can sometimes hide from these scans by only activating under specific conditions.
Remote scanning solutions often include a web-based interface that offers detailed reports on the findings. These reports provide insights into the resources that would be loaded by client browsers. Customers can justify the presence of certain scripts, ensuring that they are necessary for enterprise operations while maintaining compliance. Additionally, these tools can notify users of any changes to the scripts or security headers, enabling timely responses to new risk and maintaining the integrity of client-side security measures.
Strengths—Remote scanning solutions are easy to implement and provide a basic, limited view into a monitored web application.
Limitations—Limited visibility and accuracy can lead to potential blind spots, especially when dealing with sophisticated threats. Resources that require user login, or those requiring more complicated actions from users before they are loaded and executed, may be overlooked. Furthermore, this solution offers no protection or remediation capabilities, as it is used for detection only.
Vendor Solutions Based on CSP Headers
The HTTP Content Security Policy (CSP) response header, universally supported by modern web browsers, provides advanced client-side security capabilities. Web applications can instruct client browsers via detailed policies on what resources are necessary parts of a web application and which safe locations they can be loaded from. Web browsers can also be instructed to block or report unexpected behavior.
In their simpler form, WCRS solutions may leverage a custom CSP header directive that does not directly block any suspicious behavior and simply instructs all client browsers to report what content was loaded in near real time. Dashboards display script inventories and observe script behavior for monitored applications. Many vendor solutions will take this a step further, leveraging proprietary and open-source threat intelligence feeds to alert their customers to any known malicious content and behavior. To further protect their customers, some vendor solutions will suggest more advanced CSPs that could be implemented in “prevent mode”. This mode will automatically block unexpected scripts. However, this option works best for simple web applications managed by technically savvy organizations due to the complexity and operational stability risk.
Integrating CSP headers requires customers to modify their web applications, which can delay implementation. Despite this, the header directive is transparent in its function and does not necessitate extensive vetting. By providing accurate and timely reporting without the need for more complex vendor-provided script integration, CSP header-based monitoring offers a balanced solution that enhances security while keeping code changes minimal and transparent to customers.
Strengths—CSP headers provide accurate real-time reporting of resources and scripts executed by client browsers. This solution requires minimal changes to the web application code.
Limitations—CSP headers require basic changes to the web application, which may necessitate change control, testing, and approvals. These necessary steps may delay implementation. Moreover, implementation of optional custom CSP policies may only work well for simple web applications, as these policies are often much more complex and can cause operational impact. They can block external resources and other essential web application functionality if they are not explicitly approved ahead of time.
Solutions Based on Custom Vendor-Provided JavaScript
Many WCRS solutions require monitored applications to include custom JavaScript provided by the vendor. This option introduces risk and can extend timelines for approval and vetting. However, despite these challenges, it provides additional granular visibility of script behavior at the data element level and enables dynamic policy evaluation and enforcement.
This approach allows for the implementation of script behavior policies, which go beyond the detection and reporting of unauthorized script behaviors and actively block unwanted actions in real time. For example, certain scripts can be authorized to access credit card fields and/or perform keystroke logging, while all others are denied from performing such actions. Vendor-provided JavaScript solutions can dynamically adjust policies based on the ongoing evaluation of script behaviors, enabling more proactive and robust client-side security controls.
Implementing CSP headers with custom JavaScript requires significant changes to the web application, necessitating rigorous change control, testing, and approvals. Although preparations for this solution tend to be robust, its ability to provide granular control and advanced security features makes it a compelling choice for organizations that require high levels of WCRS.
Strengths—This solution offers granular real-time visibility and control over client-side resources at the data element level. It also offers dynamic policy evaluation and enforcement, including advanced security measures such as data firewalls.
Limitations—This solution’s granular nature requires slightly more significant changes to web applications, leading to longer timelines for vetting third-party vendor code, approval, and implementation. To this end, vendor JavaScript code must be trusted by all monitored applications, introducing additional supply chain risk.
Vendor Solution Summary
There are several options available for organizations looking to gain better insights and control over WCRS, depending on organizational security needs. These optionsFigure 5 — Web Client Runtime Security Integration Options
Conclusion
Organizations may consider the pros and cons of each of the above options before selecting solutions for their WCRS objectives. It may be the case that a single solution may not suit every website and organization, given the likely differences in the criticality of the business functions supported by the websites and the sensitivity of the information processed.
The next and final article (part 3) in this series will cover certain guidelines that organizations may find useful in operationalizing their WCRS programs.
Endnotes
1 OWASP, Static Application Security Testing (SAST)
2 OWASP, Dynamic Application Security Testing (DAST)
3 OWASP, Interactive Application Security Testing (IAST)
Sergei Vasilevsky, CISSP
Is the founder and president of ILIAM Consulting. Vasilevsky has over 20 years of cybersecurity consulting experience, beginning at a Big 4 for 7 years. ILIAM Consulting provides customized cybersecurity and compliance solutions related to application security architecture, vulnerability management, identity and access management, and regulatory compliance. Its work spans multiple industries, including finance, healthcare, and aviation. You can reach Sergei at https://www.linkedin.com/in/sergeivasilevsky/
Kamal Govindaswamy, CCSP, CISSP, CIPP/US
Is the co-founder and security practice leader at Tueoris. Govindaswamy has been a security consultant for over 20 years, beginning at a Big 4 for 6 years. He has served clients across not-for-profit, healthcare, retail, financial services, life sciences, insurance, and consumer business industries. You can reach Kamal at https://www.linkedin.com/in/kgswamy/