DOM clobbering
DOM clobbering uses specially named HTML elements to interfere with browser properties or application variables.
What it means
DOM clobbering uses specially named HTML elements to interfere with browser properties or application variables. It can matter even when script tags are removed, because injected markup may alter how later JavaScript locates resources or interprets state. Explicit variable ownership and careful sanitization reduce this ambiguity.
A practical example
A page lets users submit formatted HTML. Its script reads a resource location from a global name that can also be created by an element ID. The redesign keeps configuration in explicit application state rather than resolving it through ambiguous browser globals.
What to check
Avoid relying on document or window named properties for trusted configuration. Sanitize allowed markup, use explicit declarations, and test collisions with security-sensitive element names.
A common pitfall
Removing executable scripts does not eliminate every markup-based attack. Non-script elements can affect later trusted code through browser name resolution behavior.
Think it through
Can harmless-looking markup change what a trusted script loads?
Answer: Yes, if the script resolves a security-sensitive name through a browser property that the markup can clobber.
Markup can influence a later lookup
A fictional article viewer permits simple contributor HTML. Its JavaScript later looks for a configuration name on the window object before loading a helper resource. Browser behavior that exposes certain named elements as properties can make that lookup ambiguous. The contributor has not supplied a script, yet their markup can influence the input consumed by trusted script.
This is different from merely choosing a duplicate CSS selector. The security question is whether an attacker-influenced name can replace a value the application treats as trusted configuration. Configuration objects, resource URLs, and security-sensitive feature switches deserve explicit ownership. Application state should not silently fall back to whatever a named browser property happens to return.
Sanitization needs to consider the permitted markup and how the application uses it afterward. Removing event handlers may address one execution route while leaving name collisions relevant to later code. Use a maintained sanitizer with a policy suited to the application, and review whether its configuration handles IDs and names appropriately.
Review a name-resolution dependency
For a local paper exercise, draw a trusted script reading a resource location from a clearly declared object. Compare it with a script reading the location through an ambiguous global name. Add a contributor-controlled element with the same name and explain which design has a well-defined owner for configuration. No executable payload is needed to understand the problem.
When fixing a real finding, trace every consumer of the affected value. Renaming one element can hide the symptom while leaving the underlying name-resolution pattern elsewhere. Prefer a design that keeps trusted configuration separate from user-created document structure. Regression checks should cover permitted rich text as well as collisions, so the solution preserves normal article formatting without restoring ambiguity.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: DOM Clobbering Prevention