DOM Sanitization Module (DSM)

• DSM is a mechanism that transforms the raw DOM into a controlled, sanitized view, serving both security mediation and semantic compression purposes.
• In browser security, DSM (as implemented in SafeJS) isolates untrusted scripts via a Virtual DOM and strict policy enforcement to prevent unauthorized mutations.
• In LLM-based web automation, DSM reduces token costs by converting noisy HTML into a deterministic Semantic Skeleton, achieving high success rates in workflow compilation.

Searching arXiv for the cited papers to ground the article in current arXiv records. In recent arXiv literature, the term DOM Sanitization Module (DSM) denotes a mechanism that transforms or mediates access to the Document Object Model so that downstream components receive only a controlled representation rather than the raw, unrestricted DOM. Two distinct but related usages are prominent. In browser security, DSM-like functionality appears as a policy-enforced boundary between untrusted JavaScript and the real DOM, exemplified by SafeJS, where foreign components operate on a virtual DOM inside hermetic sandboxes and every requested DOM mutation is mediated before it can affect the page (Cassou et al., 2013). In LLM-based web automation, DSM denotes a front-end context-optimization stage that converts noisy raw HTML into a compact Semantic Skeleton for one-shot workflow compilation, thereby reducing token cost and stabilizing selector grounding (Chundru, 8 Apr 2026). This suggests a common abstraction: selective DOM exposure as a systems technique for constraining either security risk or inference cost.

1. Scope and conceptual definition

A DSM operates on the premise that the raw DOM is often an unsuitable interface. In the SafeJS setting, the problem is that any script running in a page can ordinarily read and modify the entire DOM tree and can use reflective features such as eval and dynamic property access to bypass simple restrictions. In the agentic-compilation setting, the problem is that raw DOMs are large, noisy, and unstable, often containing <script>, <style>, <svg>, tracking elements, hidden nodes, and volatile attributes that are irrelevant to workflow planning yet expensive for an LLM to ingest (Cassou et al., 2013).

Across these settings, a DSM does not merely “clean” markup. It defines what portion of the DOM is visible, which structures are retained, which attributes remain semantically authoritative, and whether proposed mutations may propagate to the real page. In SafeJS, this controlled representation is a Virtual DOM attached to a designated subtree and governed by a per-script policy. In agentic compilation, it is a sanitized HTML skeleton preserving enough structure to identify elements, infer repeated structures, and construct robust selectors (Chundru, 8 Apr 2026).

The term therefore spans both security mediation and semantic compression. The unifying principle is that the real DOM is treated as a privileged substrate whose unrestricted exposure is either unsafe or computationally inefficient.

2. Security-oriented DSMs and hermetic DOM mediation

SafeJS was designed for mashup-style pages that embed foreign or third-party JavaScript such as widgets, ads, analytics scripts, and partner components. Its objective is to prevent a foreign component from modifying the main DOM tree in unexpected ways and to ensure that all interactions between untrusted code and the real DOM pass through a controllable policy layer. The core mechanism combines Web Workers, a Virtual DOM, and a message queue (Cassou et al., 2013).

Each untrusted script runs in its own worker. By specification, workers have no access to the DOM API, do not share data, and communicate with the main thread only via string messages. SafeJS discovers scripts declared with type="text/safe-javascript", creates a dedicated worker bootstrapped with jail.js, and sends that worker a serialized copy of the target node and its content. The attributes node and policy specify, respectively, the subtree root that the script is allowed to see and manipulate and whether the script is read-only or read-write. Because the browser does not execute type="text/safe-javascript" in the main thread, SafeJS can interpose before any foreign code runs (Cassou et al., 2013).

Inside the worker, the serialized subtree is used to construct a SafeJS Virtual DOM, described as a full JavaScript implementation of DOM Level 3 forked from jsdom and adapted for browser use. The modifications include non-blocking dependency management through RequireJS, removal of file-system access, elimination of Contextify, introduction of a synthetic global object that mimics window, and a virtual console. Similar changes were applied to dependencies such as cssom, cssstyle, and htmlparser, with browserify used to bundle them for browser execution (Cassou et al., 2013).

The resulting execution model is structurally mediated:

$R_s$0

All reads and local manipulations occur inside the worker. When the untrusted script modifies the virtual DOM, SafeJS serializes the change as JSON, sends it to the main thread, checks the policy, and either ignores the update, kills the worker, or applies an equivalent update to the real DOM. The real DOM is therefore never directly accessible from the untrusted script, and the SafeJS implementation has been reported as being used in an industrial setting in the Resilience FUI 12 project (Cassou et al., 2013).

3. Policy model, confinement, and reflective features

SafeJS exposes a simple but precise policy model. For a script $s$, the policy parameter is $P_s \in \{\text{read-only}, \text{read-write}\}$, and the authorized DOM region is $R_s$, the subtree rooted at the specified node. This yields a confinement rule of the form

$$\forall s,\ \forall \text{ write operation } op,\ op \text{ is applied only if } op.\text{target} \in R_s \land \text{write} \in \text{Ops\_allowed}(s).$$

The principal invariants are that the script has no direct reference to the real DOM, that any effect is confined to its authorized subtree, and that every real-DOM write is mediated by the SafeJS runtime (Cassou et al., 2013).

Violation handling is configuration-dependent. If a change is not allowed, SafeJS can either ignore the update request or kill the worker. The paper does not specify attribute-level restrictions, but its node-scoped visibility policy and coarse read-only / read-write modes directly suggest finer-grained DSM evolutions such as whitelisting operations like appendChild or setAttribute, restricting dangerous attributes, and enforcing subtree membership for every target node. This is an inference from the policy structure rather than an explicit SafeJS feature.

A central point of SafeJS is that the security boundary does not depend on a safe JavaScript subset or source rewriting. The paper contrasts this with Caja, FBJS, and ADSafe, which rely on restricted language subsets, rewriting, or type-based verification. SafeJS instead uses browser primitives for process-level isolation. Even if untrusted code uses eval, the document it can reach is only the virtual DOM object inside the worker. Reflective operations remain possible, but only within the sandbox. Compared with iframe-based isolation, SafeJS avoids DOM access in the sandbox entirely; a same-origin iframe may still reach parent unless carefully controlled, whereas a worker has no DOM API by construction (Cassou et al., 2013).

4. DSM as context optimization in agentic compilation

In "Agentic Compilation: Mitigating the LLM Rerun Crisis for Minimized-Inference-Cost Web Automation" (Chundru, 8 Apr 2026), DSM occupies a different architectural role. The motivating problem is the Rerun Crisis: an LLM-driven web agent that repeatedly reads browser state and selects the next action incurs inference cost that scales linearly with both the number of workflow executions $M$ and the number of sequential actions $N$. The paper formalizes the continuous-loop cost as

$$\text{Cost}_{cont} = M \times \sum_{i=1}^{N} [S_i \times C_t],$$

where $S_i$ is the token count of the DOM at step $i$ and $C_t$ is the per-token inference cost. The proposed one-shot alternative is

$P_s \in \{\text{read-only}, \text{read-write}\}$0

with amortized $P_s \in \{\text{read-only}, \text{read-write}\}$1 behavior in $P_s \in \{\text{read-only}, \text{read-write}\}$2 because the LLM is called only once and execution is then deterministic (Chundru, 8 Apr 2026).

DSM is the first non-browser stage in this pipeline. The browser exposes the raw DOM or HTML; DSM performs Context Optimization; the resulting Semantic Skeleton, together with the current URL and the user’s natural-language intent, is passed to a one-shot LLM compiler; the model emits a deterministic JSON workflow blueprint; a Human-in-the-Loop verification gate may patch the JSON; and a lightweight execution engine performs browser actions without further model queries (Chundru, 8 Apr 2026).

The DSM itself applies a single DOM traversal and performs three transformations. First, Noise Eradication prunes entire <script>, <style>, and <svg> subtrees as well as base64 payloads and similar non-HTML blobs. Second, Signal Extraction removes nodes styled as display: none or visibility: hidden, concentrating the representation on visible, interactive state. Third, Attribute Cleansing strips volatile utility CSS classes while preserving semantic identifiers, especially BEM-style classes, data-* attributes, ARIA roles, and other identifiers inferred to be stable. Collectively, these operations compress token payloads by up to 85% and produce a deterministic skeleton that is more stable across reruns and minor UI changes (Chundru, 8 Apr 2026).

This semantic reduction is not merely a compression trick. It is also a selector-grounding discipline. By suppressing volatile classes and cosmetic markup, DSM pressures the model to build selectors from persistent semantic structure rather than transient presentation details.

5. Semantic skeletons, JSON blueprints, and empirical behavior

The output of the agentic-compilation DSM is described as a sanitized HTML skeleton or Semantic Skeleton. Structurally, it remains HTML or a DOM tree, but with large non-relevant subtrees removed, invisible nodes pruned, and attributes reduced to a minimal semantic core. The model is instructed to output a JSON workflow schema and to follow a Semantic Selector Priority Hierarchy that prefers ARIA roles, data-* attributes, and stable classes before resorting to fragile positional selectors such as nth-child (Chundru, 8 Apr 2026).

The blueprint produced from the sanitized skeleton includes actions such as click, fill input, select from dropdown, wait for conditions, and navigate; selectors used by the execution engine; loops and pagination logic; and extraction schemas for data-collection tasks. Because DSM preserves repeated structural patterns and semantic identifiers, it supports the inference of cards, tables, pagination controls, and form semantics while suppressing hidden clones, experimental UI variants, and tracking markup. When a selector later fails at execution time, the system uses Lazy Replanning: it halts, reruns compilation on an updated DOM snapshot, and performs targeted selector healing while retaining deterministic control flow (Chundru, 8 Apr 2026).

The reported empirical effects are indirect but substantial. Zero-shot compilation success rates are reported as 80–94% across the studied tasks. The paper further reports 92% successful blueprints and 98% execution accuracy for High-Volume Paginated Extraction, 80% successful blueprints and 95% execution accuracy for Form Filling, and 94% successful blueprints and 96% execution accuracy for Tech Stack Detection. The modularity of the JSON intermediate representation allows minimal HITL patching to elevate execution reliability to near-100% (Chundru, 8 Apr 2026).

Token counts and compilation costs reflect the same design. After sanitization, full compilation calls including prompt and intent fit roughly in the 10k–12k input-token range in the reported experiments: Sonnet 4.5 used 11,628 input tokens and 1,670 output tokens, Opus 4.6 used 11,628 and 1,340, GPT-5.2-Codex used 9,951 and 1,447, Qwen3.5 397B used 10,738 and 3,000, and Qwen3 Coder Next used 10,536 and 550. Per-compilation costs are reported between 0.002 USD and 0.092 USD across five frontier models. By contrast, a continuous agent executing a 5-step workflow over 500 iterations is estimated at approximately 150.00 USD, or near 15.00 USD even with aggressive caching (Chundru, 8 Apr 2026).

The same paper also delineates limits. DSM-based compilation is tuned for conventional server-rendered or SPA-based applications with standard HTML structure. It is less suitable for canvas-rendered or WebGL interfaces, highly obfuscated or non-semantic HTML, or cases where over-pruning would remove useful hidden state. Some complex form-filling failures are attributed to reasoning depth rather than DSM itself, but the pruning strategy entails an unavoidable information-loss versus token-savings trade-off (Chundru, 8 Apr 2026).

6. Regex-based sanitization and the ReDoS attack surface

A third line of work is relevant when DSMs implement sanitization rules with regular expressions. "Exploiting Input Sanitization for Regex Denial of Service" formalizes a regex $P_s \in \{\text{read-only}, \text{read-write}\}$3 as ReDoS-vulnerable in a given engine when there exists an input family $P_s \in \{\text{read-only}, \text{read-write}\}$4 such that $P_s \in \{\text{read-only}, \text{read-write}\}$5 grows linearly in $P_s \in \{\text{read-only}, \text{read-write}\}$6 while the runtime $P_s \in \{\text{read-only}, \text{read-write}\}$7 grows super-linearly, for example $P_s \in \{\text{read-only}, \text{read-write}\}$8 or $P_s \in \{\text{read-only}, \text{read-write}\}$9. The practical mechanism is catastrophic backtracking in mainstream backtracking engines such as those used by JavaScript, Java, Python, and PCRE. For DSMs that run regexes over untrusted DOM input or expose client-visible validation rules, this makes sanitization logic part of the attack surface (Barlas et al., 2023).

The paper’s Consistent Sanitization Assumption states that client-side sanitization logic published in HTML, JavaScript, or API schemas is consistent with, and a subset of, server-side sanitization logic. Under this assumption, publishing regexes in forms or schemas may reveal patterns that are also enforced on the server. The study analyzed the HTML forms of 1,000 services and the APIs of 475 services. Of these, 355 services publish regexes; 17 services publish unsafe regexes; and 6 services are vulnerable to ReDoS through their APIs, affecting 6 domains and 15 subdomains. Both Microsoft and Amazon Web Services patched their services following disclosure (Barlas et al., 2023).

For DSM design, the defensive lessons are specific. Dangerous constructs include nested quantifiers over overlapping subpatterns, overlapping alternations, and backtracking-heavy uses of .* under trailing constraints. The paper recommends length limits, automated ReDoS testing of sanitization regexes, and safe or bounded engines where possible. It also highlights an architectural mitigation drawn from its patch to Ajv: abstract the regex engine behind a factory or pluggable interface so that a safe engine such as RE2 can be substituted without rewriting the sanitization logic. Applied to DSMs, this means that imported schemas and client-visible validation rules should be treated as untrusted configuration and evaluated with explicit attention to worst-case regex complexity (Barlas et al., 2023).

Taken together, these results clarify a frequent misconception. A DSM is not necessarily a benign preprocessing layer. In security-oriented settings it is a policy-enforcement boundary for DOM capabilities; in agentic compilation it is a context-reduction and semantic-grounding stage for deterministic workflow synthesis; and when it uses regex-based validation it may itself expose a measurable denial-of-service surface.