The modification of a webpage’s structure or content after it has loaded in the browser. In security terms, it matters because an extension can replace links, forms, or text with attacker-controlled content while the user still believes the page is legitimate.
What DOM Rewriting Actually Changes
DOM rewriting is a browser-side content mutation problem, not just a visual change. The page’s document structure can be altered after load, so the browser may display one thing while the underlying links, form targets, or labels now point somewhere else.
That distinction matters because users tend to trust what they see on a loaded page. If an extension or injected script rewrites the DOM, the content can look normal while the interaction path has been redirected to an attacker-controlled destination.
How DOM Rewriting Works in Practice
Rewriting happens when code with page access changes HTML nodes, text, attributes, or event-handling behavior after the initial render. It can replace a login link, swap a button action, hide warnings, or rewrite text that the user relies on to make a decision.
The mechanism is powerful because it operates inside the same browsing session as the legitimate site. From the user’s point of view, the page can appear authentic until the moment an altered element is clicked, submitted, or copied.
In defensive terms, the security issue is not the browser feature itself, but the trust boundary it crosses. Any component allowed to manipulate the page DOM becomes part of the page’s effective attack surface, especially when it can touch navigation, forms, or security-relevant instructions.
Why DOM Rewriting Is Security-Relevant
DOM rewriting can turn a benign-looking page into a phishing or redirection vector without changing the site’s origin. A malicious extension, compromised script, or injected payload may preserve the brand and layout while silently substituting the action behind a control the user thinks is safe.
That creates a classic trust problem: the visible content no longer guarantees the actual behavior. It is especially dangerous when users rely on page text for approvals, payment details, account actions, or other high-value decisions.
Security teams should treat the possibility of in-session content mutation as a risk to user verification, integrity of displayed information, and the reliability of page-based workflows. A page that can be rewritten after load is not the same as a page whose rendered state can be trusted end to end.
Where DOM Rewriting Sits in the Browser Security Model
DOM rewriting sits at the intersection of browser extension security, script trust, and content integrity. It is closely related to UI tampering, but it is broader than a single visual trick because it can alter the behavior of links, forms, prompts, and other interactive elements.
The important question is not whether the page was originally legitimate, but whether the user can still rely on the page state at the time of interaction. In environments where extensions or injected code are permitted, content integrity becomes a runtime property, not a static property of the initial page response.
For that reason, DOM rewriting is often discussed alongside controls that limit script authority, constrain extension behavior, and reduce the ability of untrusted components to modify security-sensitive parts of the page.
Risk and Threat Considerations
DOM rewriting creates a practical integrity risk because the user’s trust in visible content can be exploited after the page has already loaded. When a malicious component alters the DOM, the attack can redirect clicks, submissions, or copied values without obvious signs of compromise.
Failure mechanism: an extension, injected script, or compromised page dependency rewrites interactive elements or displayed text after render, allowing attacker-controlled behavior to masquerade as legitimate page content.
Impact: users may disclose credentials, approve fraudulent actions, submit data to the wrong destination, or follow links that no longer match the original site’s intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | DOM rewriting alters page inputs and actions at runtime, making integrity controls relevant. |
| AC-6 — Least Privilege | Limiting extension and script authority reduces who can rewrite trusted page content. | |
| Recommendation — Validate and constrain page-delivered inputs and script-driven mutations that can change user-facing behavior. Restrict browser and extension privileges to the minimum needed to modify page content. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Content integrity depends on protecting page and extension assets that influence what users see. |
| Recommendation — Protect page assets and trusted code paths so hostile modifications are harder to introduce. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Client-side trust boundaries and DOM mutation risks are part of secure browser-facing architecture. |
| Recommendation — Design browser-facing features so untrusted scripts cannot silently alter critical user interactions. | ||
| MITRE ATT&CK | T1056 — Input Capture | DOM rewriting can be used to tamper with fields and interactions users believe are legitimate. |
| Recommendation — Hunt for page-tampering behavior that changes what users enter or click in the browser. | ||
Practitioner Guidance
What to watch for: pay attention to browser components or page features that can modify links, buttons, forms, or security prompts after load. In practice, the key governance question is which code is allowed to alter what the user sees and where that code is sourced from.
Practitioner takeaway: if page content can be rewritten at runtime, treat rendered trust as conditional, not absolute.
Related resources from NHI Mgmt Group
- What is the difference between identity orchestration and application rewriting?
- Who is accountable when an AI assistant performs a sensitive action after DOM manipulation?
- What should organisations do when an agent starts mutating state or rewriting memory?
- How should teams reduce IAM technical debt without rewriting every application?