Cybersecurity glossary

What is DOM Clobbering?

Learn what DOM clobbering is, how HTML name and id attributes can overwrite global JS objects, how attackers chain it with XSS sinks, and how to prevent clobbering bugs.

Application securityUpdated July 23, 2026
Also known asClobberingNamed property clobberingHTML element global overwrite

Definition

DOM clobbering is a browser quirk-driven technique where attacker-controlled HTML elements with certain id or name attributes overwrite or shadow global JavaScript properties, causing application code to trust attacker-controlled objects instead of built-in APIs or expected values.

Why DOM clobbering matters

Security filters and client scripts often assume window.x means what developers assigned. In HTML, an element with id="x" may create window.x automatically. DOM clobbering abuses that legacy behavior so attacker markup hijacks control flow—sometimes without an immediate <script> tag.

It is a favorite building block for bypassing naive sanitizers and client-side security checks.

How DOM clobbering works

1

Inject HTML with crafted id/name

Attacker supplies markup that the application inserts into the DOM.

2

Browser creates named properties

Elements become reachable as globals or through document collections.

3

Application reads the wrong object

Code expecting a string, function, or built-in now receives an Element or HTMLCollection.

4

Security logic fails open

Checks like truthiness, toString coercion, or URL assumptions misbehave.

5

Follow-on sink abuse

Clobbered values flow into HTML/script URL sinks and produce XSS or logic bugs.

Common patterns

Global overwrite

id matching a library global replaces the expected object.

Form/anchor coercion

Elements stringify to attacker-controlled values used as URLs.

Collection tricks

Multiple elements create array-like collections that bypass simple filters.

Sanitizer blind spots

Filters strip script but leave id/name that still clobber.

Defenses

ControlHow it helps
Sanitize id and nameRemove or tightly allowlist attributes that create named properties
Avoid implicit globalsKeep references to APIs in local consts; do not trust window lookups
Use safe DOM APIsPrefer textContent and explicit createElement over HTML concatenation
Trusted TypesReduce string-to-sink accidents after clobbering confuses control flow
Strict CSPLimits follow-on script execution even if markup is injected

Hardening checklist

  • Treat id/name on untrusted HTML as dangerous attributes.
  • Ban or rewrite colliding ids that match sensitive global names in tests.
  • Store built-in references early (e.g., const createElement = Document.prototype.createElement).
  • Assume HTMLCollections can appear where strings were expected.
  • Update sanitizer libraries and enable their clobbering protections when available.
  • Add regression payloads for form/anchor/base clobbering patterns.
  • Review client checks that use truthiness on possibly clobbered values.
  • Combine with CSP and Trusted Types for defense in depth.

The practical takeaway

DOM clobbering turns attacker-controlled id/name markup into hostile JavaScript globals and objects. It often bypasses filters that only think about <script> tags.

Sanitize named attributes, stop trusting implicit globals, and assume injected HTML can reshape your runtime environment—not only inject scripts.

Related security terms

Frequently asked questions

What is DOM clobbering in simple terms?

An attacker injects HTML with special id/name values so that JavaScript variables you thought were built-ins now point at their elements instead.

Why does this happen?

Browsers expose some elements with id/name as properties on window/document for legacy compatibility. That creates surprising global bindings.

Is DOM clobbering itself XSS?

Not always. Clobbering is often a primitive that breaks security checks or feeds attacker objects into sinks that then become XSS.

What are common clobbering targets?

Properties like location, attributes of forms/anchors, collections used by libraries, and custom globals that collide with element ids.

How do you prevent DOM clobbering?

Sanitize id/name aggressively, avoid relying on implicit globals, use local references to APIs, enable Trusted Types, and harden sanitizers against known clobber patterns.

Can Content Security Policy stop clobbering?

CSP does not remove named-property behavior. It may still block resulting script execution depending on policy strength.

Do frameworks prevent clobbering?

Some reduce risk by not reflecting arbitrary attributes, but server-rendered HTML and sanitizer gaps can still introduce clobberable markup.

References

Explore authoritative guidance and frameworks related to dom clobbering.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary