Cloudflare Opens Client-Side Security to All, AI Detection Cuts False Positives 200x
Client-side attacks have a boring superpower: they steal data without breaking anything. The page still loads, checkout still completes, and all it takes is one malicious script tag. In January 2026 Sansec reported a browser keylogger on an employee merchandise store of a major U.S. bank harvesting personal data, credentials, and credit card information. In September 2025, malicious npm package releases exposed countless front-end apps to crypto-stealing in the browser.
For ordinary visitors these attacks are nearly invisible: the script runs quietly during page load, collects form input, reads and writes cookies, hijacks redirects, and can even exfiltrate session tokens to third-party domains after you log in. The Magecart attacks that swept major media in 2019 are still the textbook case — attackers breached a third-party supplier of e-commerce sites, injected scripts into checkout pages, and harvested hundreds of thousands of card records within a month. This kind of supply-chain client-side attack is exactly what a product like Client-Side Security exists to stop.
In March 2026 Cloudflare responded by making Client-Side Security Advanced available to self-serve users and giving domain-based threat intelligence away to all customers.
The Core Challenge of Client-Side Security
Cloudflare's client-side security assesses about 3.5 billion scripts per day, with roughly 2,200 unique scripts per enterprise zone. The hard part is not volume but volatility: about a third of scripts update their code within any 30-day window. Manually approving every new DOM interaction or outbound connection would paralyze the development pipeline.
Detection therefore focuses on what a script is trying to do, analyzing the Abstract Syntax Tree (AST) to identify malicious intent patterns regardless of obfuscation.
A GNN + LLM Cascade
The frontline engine is a Graph Neural Network (GNN) that learns structural representations on the JavaScript AST, generalizing across variable renaming, minification, and obfuscation. Tuned for high recall to catch zero-days, its false-positive rate is already under 0.3%, but at 3.5 billion scripts per day that still means disruptive noise.
The fix is a cascading architecture with an LLM as a second opinion:
- Every script is first evaluated by the GNN; benign predictions terminate immediately at minimal latency for the vast majority of traffic.
- Scripts flagged as potentially malicious go to an open-source LLM hosted on Workers AI (currently gpt-oss-120b) for semantic analysis.
- If the LLM decides the script is benign, it overrides the GNN verdict.
The results are dramatic: the overall false-positive rate drops from about 0.3% to 0.1% (roughly 3x), while per unique script it falls from 1.39% to 0.007% (roughly 200x), removing millions of false alarms per day. Because the LLM acts as a reliable precision filter, the GNN threshold can be lowered to catch even more novel attacks.
Real-World Catch: The core.js Router Hijack
The architecture already caught a zero-day in the wild: a heavily obfuscated core.js script injected through compromised browser extensions, targeting Xiaomi OpenWrt routers. It queried the router's WAN config, overwrote DNS settings to route traffic through public DNS servers, and even tried to lock out the owner by changing the admin password. Traditional platforms like VirusTotal had not yet detected it, but the GNN pierced the obfuscation and the LLM confirmed the intent.
Comparing Detection Approaches
| Approach | How It Works | Strength | Limitation |
|---|---|---|---|
| Rules / blocklists | Match known malicious signatures and domains | Catches known attacks | Misses variants and obfuscation |
| Static analysis / AST | Parse code structure for suspicious patterns | Captures logic features | Higher false positives |
| GNN | Learns structural representations on the AST | Generalizes renaming and obfuscation | Needs lots of labeled samples |
| LLM semantic analysis | Understands code intent | Precisely judges complex samples | Higher latency and cost |
These four approaches are not mutually exclusive; they layer on top of each other. Rules catch known attacks, AST and GNN surface unknown patterns, and the LLM pushes precision highest. Cloudflare's cascade is exactly that division of labor: high recall and high precision handled separately — one makes sure nothing is missed, the other makes sure operators are not flooded.
Steps to Enable Client-Side Security
For a site on Cloudflare, enabling it roughly takes four steps:
- In the Cloudflare dashboard, go to Security → Client-Side Security and add the domains and scripts you want to monitor.
- Run in "observe only" mode for one to two weeks first to collect a baseline of which third-party scripts normally load.
- Once alerts look clean, switch to "block" or "report" mode.
- Route alerts to Slack, email, or a webhook and schedule a weekly review.
One caveat: client-side security only protects pages proxied through Cloudflare. Traffic that bypasses Cloudflare to reach your origin directly is not inspected and needs separate handling. Treat it as a front-end supply-chain health check rather than a set-and-forget switch to get the most value.
What It Means for Websites
Client-side security is often the weakest link for small and medium sites. Start with the basics: harden response headers with security headers configuration, and follow the website security checklist and website security best practices. More content is in the Security Hardening category.
Reference: Cloudflare Client-Side Security docs https://developers.cloudflare.com/client-side-security/
Source: https://blog.cloudflare.com/client-side-security-open-to-everyone/