DOM injection is the alteration of a webpage’s document structure by inserting, replacing, or rewriting elements in the browser. It matters for identity security because it can change what users see, click, or submit inside a trusted session, turning client-side code into a manipulation layer.
Expanded Definition
DOM injection is a client-side manipulation pattern in which script, markup, or element changes are introduced into the browser-rendered document object model after a page loads. In identity workflows, the risk is not limited to visible page tampering. It can alter login prompts, consent dialogs, token-handling flows, or form destinations inside an otherwise trusted session. The boundary between legitimate dynamic rendering and abusive DOM rewriting is still evolving, so definitions vary across vendors and security teams. For a standards-oriented baseline, NIST Cybersecurity Framework 2.0 frames the broader need to protect user-facing systems and transaction integrity, while NHI-focused governance needs to account for browser-side trust as part of the identity control plane. NHIMG’s Ultimate Guide to NHIs is useful here because DOM injection often intersects with exposed API keys, embedded scripts, and agent tooling that already operate with authority in the browser. The most common misapplication is treating DOM injection as only a frontend display issue, which occurs when teams overlook how altered elements can redirect authentication, consent, or submission behavior.
Examples and Use Cases
Implementing controls against DOM injection rigorously often introduces friction for developers, requiring organisations to weigh rapid UI iteration against stricter review of client-side code paths.
- A malicious extension rewrites a passwordless sign-in prompt so a user submits a legitimate credential to an attacker-controlled endpoint.
- A compromised third-party script changes a token exchange form, causing session data to be sent to an unintended domain.
- An internal agent console injects extra UI elements that expose privileged actions to a broader set of operators than intended.
- A support workflow page is modified in-browser to hide warnings before an admin approves a sensitive API key rotation.
- A phishing kit imitates a trusted application by rewriting DOM elements after load, making the login flow appear authentic.
These scenarios are closely related to client-side attack paths described in the OWASP Top 10, especially where unsafe input handling and script trust meet browser execution. For NHI governance, the same pattern matters when service accounts, agent sessions, or embedded secrets are reachable through a manipulated interface. NHIMG’s Ultimate Guide to NHIs is a helpful reference for understanding how broad NHI exposure makes even small browser-side changes operationally significant.
Why It Matters in NHI Security
DOM injection becomes an NHI security issue when browsers are used to administer identities, approve workflows, or access credentials that should never be exposed through mutable page content. If an attacker can rewrite the document after load, they may be able to capture tokens, misdirect approvals, or obscure privileged actions in ways that normal server-side logging does not immediately reveal. This is especially concerning in environments where secrets are already spread across code and tooling. NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, highlighting how browser-side manipulation can become a direct path to identity compromise. The operational answer is not just stronger filters. It requires strict content integrity, script governance, sandboxing, and careful separation between human-facing UI and privileged NHI controls, supported by guidance from NIST Cybersecurity Framework 2.0 and the governance themes in Ultimate Guide to NHIs. Organisations typically encounter DOM injection’s real cost only after a credential or approval flow is abused, at which point browser integrity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Client-side manipulation can expose or reroute NHI secrets and session flows. |
| NIST CSF 2.0 | PR.DS-1 | DOM integrity supports protection of data in use and user-facing transaction paths. |
| OWASP Agentic AI Top 10 | LLM-08 | Agent UIs can be altered in-browser to change tool actions or approvals. |
Treat agent consoles as high-risk surfaces and harden prompts, actions, and approvals against DOM changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
