The Sharp Rise in DOM Injections: Why Traditional Anti-Fraud Solutions Are Failing

Most anti-fraud and security systems today analyze only the finished transaction: the signals it carries and how closely the user’s behavior matches established norms. For years, cross-site scripting (XSS) attacks were considered relatively easy to detect and control. Malicious code was injected through request parameters, executed in the browser, and left obvious traces — in the URL, server logs, and page behavior. Classic scenarios such as stored XSS and reflected XSS could typically be identified and blocked at the application layer, via web application firewalls (WAFs), or through server-side logic.

Today, the very structure of these attacks has changed. The threat has evolved into DOM-based XSS, and the starting point of compromise has shifted directly into the browser. Instead of overt injection, attackers now interfere with the page after it has loaded — manipulating the DOM (Document Object Model), which controls the interface structure, dynamic elements, and behavior of web applications.

As front-end architectures grow more complex, dependence on third-party scripts increases, and specialized tools for browser manipulation become widespread, transactions are increasingly formed inside an already-tampered client environment. The server receives what appears to be a perfectly valid request, and monitoring systems see “normal” signals — even though the user is actually interacting with a modified page or functionality.

In this article, we break down:

• How XSS has evolved into DOM injections and client-side hijacking (also known as Man-in-the-Browser or MITB attacks);
• How and to what extent this problem manifests across different regions of the world;
• Why classic anti-fraud and security approaches are blind to these scenarios;
• Which defense strategies actually work.

Traditional transaction analysis completely misses the stage at which the transaction is formed — and that is precisely where a growing share of attacks, showing exponential growth, now takes place.

What Is Client-Side Hijacking (MITB Attack)?

Modern attacks increasingly occur not through visible changes in the address bar, but silently inside the user’s browser — without any page reload, URL modification, or obvious server-side footprints. The user works with an altered client environment, while the server and many anti-fraud systems continue to see what looks like a legitimate session.

This is the core shift: the threat has moved from detectable server-side anomalies to stealthy manipulation of the interface logic and user behavior directly in the browser. “Hijacking” in this context means covert takeover of control on the client side.

How XSS Moved into the Browser: From Server Vulnerabilities to DOM Attacks

Classic XSS was straightforward. Malicious code would enter via a URL parameter — for example, ?search=<script>...</script> — execute immediately in the browser, and betray itself through visible signs.

DOM injections work differently. Instead of noisy URL-based attacks, adversaries modify critical page elements after the page has loaded. For instance, they might change document.querySelector('.payment-form').action so that the payment form still looks and functions normally, but all data is quietly forwarded to an attacker-controlled destination or contaminated with noise that affects risk scoring.

This substitution can occur through malicious browser extensions, compromised third-party scripts, tainted NPM packages, specialized or infected browsers, device-level malware, or any code that gains access to the DOM.

From the server’s perspective, the problem is that it often receives a completely normal-looking request. Backend systems register standard user activity. Even WAFs see no suspicious URL, attack signature, or error. In this new reality, traditional server-oriented anti-fraud tools are effectively blind to the very fact of interference.

The Most Dangerous Browser APIs in Attacker Hands

Attackers do not need to invent new tools. They simply repurpose standard browser APIs — the very same ones used for legitimate interface operations — turning them into mechanisms for interception and substitution.

The key target is events. The most obvious scenario is intercepting the submit event. At that moment, the user has already filled out the form, the data is ready to be sent, and from the application’s logic standpoint, everything is complete. This is where malicious code gains maximum control: it can copy the entered data, modify it, or completely hijack the submission and redirect it elsewhere.

The user sees nothing unusual — they receive the standard confirmation screen (“Payment successful”). Yet the submit event is only part of the picture. In practice, attackers can gain access to entire chains of user actions or enough of them to compromise the user or account.

Modern malicious code rarely limits itself to one action. Alongside the main attack — such as changing form.action or intercepting data — it generates background activity: creating and removing DOM nodes, attaching additional event handlers, sending harmless network requests, triggering unnecessary interface reflows, or overriding core browser and WebView APIs. All of this blends seamlessly into the normal flow of client-side events, making it extremely difficult for logging and monitoring systems to distinguish the anomaly from legitimate front-end noise.

Growth Dynamics of Client-Side Injections

Over the past three months, we have observed significant differences in the level of client-side injections across regions. In some markets, this has already become a systemic problem with high attack penetration; in others, it remains isolated cases for now.

Working across a large number of countries, we have noticed a clear trend: the more companies and regulators in a market invest in protective measures, biometrics, “cool-down” systems against social engineering, and similar defenses, the higher the growth rate of dangerous DOM injections. This suggests that as traditional defenses strengthen, attackers are increasingly shifting to client-side vectors.

Below is a breakdown by key regions, showing where the risk is currently highest and where it is beginning to accelerate.

Tactics of These High-Risk Threats

Modern malicious code rarely relies on a single action. Alongside core manipulations such as changing form.action or intercepting data, it generates background activity: creating and removing DOM nodes, attaching extra handlers, sending innocuous network requests, triggering unnecessary reflows, or overriding base APIs. This “noise” dissolves into the stream of legitimate client events, making anomalies hard to spot in logs or monitoring.

A High-Risk Example: Web3 and Crypto Wallets

One particularly dangerous category involves crypto wallet interfaces. Here, malicious code replaces the recipient address, QR code, or confirmation elements. Users typically trust the familiar interface and rarely verify every detail. This is an attack on the trusted interface: visually nothing changes, but critical data has already been altered. Given the irreversible nature of blockchain transactions, the consequences are final.

This risk is most often associated with malicious browser plugins. Key abused APIs include:

Storage API

localStorage, sessionStorage, and IndexedDB: Frequently used to store tokens, session identifiers, and service parameters. Malicious code can read these values to hijack the session or modify them to change application behavior at the right moment. Once a token is obtained, the attacker can continue acting on behalf of the user outside the current session — without re-authentication and without obvious signs of compromise.

Canvas API

In interfaces where critical data is rendered via canvas, attackers can alter displayed information such as card numbers, amounts, or wallet addresses.

Navigator.sendBeacon

A legitimate API used for analytics and telemetry, making it ideal for stealthy data exfiltration. Data can be sent at the moment the tab is closed, when the user no longer expects network activity. Such requests appear as ordinary telemetry events and rarely raise suspicion.

Why Classic Anti-Fraud Systems Are Blind

Traditional anti-fraud solutions ask one main question: “Is this a real user?” DOM injections operate on an entirely different level. The user can be completely legitimate, logging in from a familiar device and following a standard behavioral pattern. The risk emerges after the page loads, when the interface logic is silently altered inside the browser. The session looks normal to the anti-fraud system — IP address, device fingerprint, and behavior all fit the user’s profile. Meanwhile, the form submission is intercepted, details are substituted, and part of the data is sent elsewhere.

Why Machine-Learning Behavioral Features Don’t Help

Behavioral anti-fraud models examine features such as form-fill timing, mouse movements, typing rhythm, pauses, error rates, and the speed of clicking “Pay.” Sophisticated DOM injections are designed to perfectly imitate these signals:

Form filling is not instantaneous. Malicious code inserts data with short random delays between characters (typically 80–120 ms), making it appear human.

Mouse movements are generated with natural trajectories: smooth curves, pauses, and minor deviations that advanced automation tools now produce convincingly.

As a result, the behavioral model confidently classifies the activity as coming from a real person.

Credit Bureaus and Biometrics Also Fall Short

A credit bureau may correctly identify the customer as low-risk — and it would be right, because the attack does not touch the credit history. It happens live inside the browser during the session. Behavioral and physiological biometrics focus on mouse movements, typing patterns, gestures, facial recognition, or liveness detection. But if the client-side attack operates within a normal session, preserves the external behavioral pattern, and carefully mixes in plausible synthetic signals, even biometrics will miss the fact that the page logic has been tampered with. Attackers simply ride along with the legitimate user through all checks.

Antivirus Solutions Provide Limited Protection

Traditional antivirus tools also fail to fully address this threat. They rely on blacklists, integrity checks, known malware signatures, suspicious files, and malicious URLs. Dangerous DOM injections often slip through these defenses — especially when they involve noise generation or multi-stage scenarios where each individual action looks harmless. Protection needs to move away from evaluating isolated actions, procedures, or files toward assessing the overall consequences across the entire session, including technical behaviors that are invisible to the end user (such as session initiation and termination). This approach goes far beyond what classic antivirus solutions were designed to handle.

What Needs to Be Analyzed

It is no longer sufficient to look only at who the user is, where they came from, how they moved the mouse, or basic browser and operating system integrity. Real-time environment integrity must also be monitored: Has the DOM been altered? Has the form or form.action been changed? Have unexpected submit handlers appeared? Have data been sent via sendBeacon? Have tokens been read from storage at suspicious moments? Have hidden fields, overlays, or iframes suddenly materialized?

Analysis must cover not only user behavior but also the integrity of the environment in which that behavior takes place.

Effective Defense Strategies: From Static Analysis to DOM Integrity Monitoring

Server-side protection alone is not enough — not because it is ineffective, but because it cannot see the full picture. Since the attack lives in the browser, effective defense must be able to look there as well.

1. Subresource Integrity (SRI) informs the browser of a cryptographic hash for external JavaScript files. If the file changes, it will not load. The 2024 polyfill.io incident showed that threats can strike through compromised supply chains, simultaneously affecting thousands of sites without any individual site being “hacked” in the traditional sense. SRI works well for static external resources but does not help if the authorized script itself performs malicious logic or is dynamically injected by the user (for example, via browser extensions or plugins).
2. Content Security Policy (CSP) with reporting restricts where a page can load scripts from. The report-uri directive allows collection of violation signals in production — detecting attempts at inline injections or loading scripts from unauthorized domains before they become full incidents.
3. DOM Monitoring is currently the most advanced and effective approach. A lightweight client-side script continuously checks the integrity of critical elements: form structure, submission targets, appearance of hidden fields, unexpected event handlers, iframes, overlays, and violations of core APIs. When a deviation is detected, it sends a risk signal to the anti-fraud system, triggers additional verification, or terminates the session at the server level. The key difference from reactive systems — which only detect attacks after they have occurred through logs, events, or transaction outcomes — is that this approach catches the threat in real time while it is still developing.

The Future of Protection — Client-Side Zero-Trust: JuicyScore and JuicyID

In the past, a page loaded from a “correct” domain was trusted by default. In the world of DOM injections, that assumption no longer holds. The principle of client-side Zero-Trust means that even inside your own page, you cannot blindly trust that the DOM, event handlers, third-party scripts, and displayed details have remained unchanged. Both user identity and the integrity of the client environment must be verified.

This is exactly the principle behind JuicyScore solutions. JuicyScore analyzes non-personal data to assess session risk and protect online users from fraudsters. It combines behavioral characteristics, device and browser data, and detection of various anomalies — including randomization, noise injection, and other manipulations associated with high fraud risk.

Additionally, JuicyScore API v17 introduced new attributes in the response vector specifically designed to detect injections at different risk levels — directly relevant to this threat. We are actively developing this direction and plan to further expand the classification of DOM injection risks in the near future.

JuicyID is a more specialized product for account protection. It identifies risky devices and behavior patterns, reducing the risk of account takeover while avoiding excessive checks for legitimate users. Its device authentication technology, powered by JuicyDeviceID stable digital fingerprinting in combination with other JuicyScore attributes, allows analysis of the exact environment in which the session is occurring — the layer that remains a blind spot for traditional systems.

The boundary that needs protection has shifted. It no longer lies only at the server or at user identity level. It now runs through the browser, through the structure of the page, and through everything that happens between data entry and the final button click.

An anti-fraud strategy that fails to account for the client layer operates with an incomplete risk picture. And this blind spot is already being actively exploited.

The era of relying solely on post-transaction analysis is ending. Effective protection in today’s environment requires continuous, real-time validation of the client-side environment where transactions are actually born. Only then can organizations close the growing gap that DOM injections and client-side hijacking continue to widen.