Web application firewalls (WAFs) emerged in the early 2000s to filter malicious HTTP traffic between clients and servers. They excel at blocking many things: SQL injection, cross-site scripting, and known attack signatures. At the time, that was good enough.
However, in 2026, scripts are now able to execute entirely inside the browser. This enables them to harvest payment details in real time, while also sending stolen data to an attacker’s domain. In the shift to the browser, legacy tools lost visibility and coverage.
Where they break down in 2026
A WAF inspects traffic traveling to your server. However, scripts that read form fields, contact external domains, or harvest session data never cross over with what the WAF is looking for. A third-party analytics tag can start exfiltrating data and trigger no alerts because the behavior happens entirely on the client side.
AI-driven bots have exacerbated this issue. Modern bots can replicate human characteristics with enough precision to avoid most server-side detection. They can solve CAPTCHAs or simulate a human-like mouse movement, for instance. These detection methods are simply not enough for today’s security environment. As shown in the security firm cside’s 2026 web security report, legacy tool performance is lagging behind. WAFs and scanners missed the majority of client-side threats in controlled scenarios. These include script injection, data harvesting, and session manipulation. These are fundamental weaknesses in the infrastructure of legacy tools.
Repositioning for a new kind of security
The modern web page is a collage of many things. It’s assembled from dozens of third-party assets. These include scripts, tags, and pixels. These elements all have full access to the DOM. A typical e-commerce checkout page, for example, might load scripts from analytics platforms and A/B testing tools. Each of those scripts can read form fields and access cookies, whilst containing code that your company didn’t write. In practice, this means you cannot audit it in real time from the server side.
Magecart-style attacks are also enabled to go after these vulnerabilities. A Magecart can compromise a third-party vendor, which enables it to inject skimming code into a script. On the server side, the merchant’s WAF tells you that it’s business as usual. The server logs will agree. Meanwhile, the attack runs undetected until a cardholder reports fraud. At this point, your team has to play defense after the fact.
Session hijacking via the browser takes advantage of this as well. Malicious code reads session tokens from cookies or local storage, which are then sent to an external endpoint. This gives attackers authenticated access to user accounts. The server-side is unable to trigger any alerts, since the session itself comes back as valid.
Luckily, PCI DSS 4.0.1 recognized this. The standard now requires organizations to monitor and authorize all scripts executing on payment pages. It puts controls in place to detect unauthorized modifications, imposing requirements that cannot be met with a WAF alone.
What should I replace a WAF with?
To meet PCI DSS 4.0.1, companies need tooling that operates on the client side.
Tools that monitor the browser can use a JavaScript execution environment to observe suspicious behavior as it occurs. They can detect a script that suddenly starts reading payment fields, or an outbound request to a domain that was not present yesterday.
Behavioral analytics builds a baseline for what third-party scripts do and alerts when there are disruptions in the behavior patterns. These signals would be invisible to server-side tools, but become detectable using behavioral analytics.
Keeping track of script inventory can also give insight into the scripts that are running on your pages. It sheds light on what permissions they have and what they are doing. That inventory is the bedrock for security controls and PCI DSS 4.0.1 compliance.
Lastly, fingerprinting in the browser can identify bots that impersonate human behavior. This includes rendering patterns, JavaScript engine characteristics, and interaction timing. Effective fingerprinting can, therefore, expose automation in ways that the server-side simply can’t.
For more in-depth analysis, cside’s guide to client-side security tools provides resources organized by category for evaluating client-side security tools. It also teaches you how to assess vendor claims against an actual threat scenario.
Make sure to audit your browser layer
Most organizations quite simply do not know what scripts are running on their pages today. If you want to be sure your organization is safe, your audit should begin here.
Start by pulling a complete script inventory from your production pages, the ones that are publicly visible and face the most risk of being attacked. Cross-reference what you’re running against what you authorized, making sure to identify every outbound network destination those scripts are contacting.
That exercise usually surfaces unauthorized scripts, stale tags from vendors you might not even be using, and supply chain exposure you had no idea about. It is also the first step toward PCI DSS 4.0.1 compliance if you handle payment data.
In short, legacy web security tools were built for a different internet. Organizations in 2026 are now responsible for more than just the server-side. To keep you and your customers safe, the client side simply cannot be ignored.
