Testing Client Side Dom Vulnerabilities

Testing client-side DOM vulnerabilities: the server never sees it

A whole class of vulnerabilities never touches the server: the tainted input is read and the dangerous action taken entirely in the browser, so server-side review and server logs see nothing. The source is a URL fragment, a message, a piece of markup, or a global the attacker can influence; the sink is a script execution, a corrupted object, or a leaked cross-origin fact. Testing them means tracing taint inside the page, from client source to client sink.

When to use

• You are reviewing a single-page app, heavy client-side JavaScript, or a browser extension.
• Code reads the URL, a message, storage, or the DOM and writes it into a sink.
• The server sees none of the payload, so server-side testing found nothing.

Scope check

Test pages and extensions you own or are authorized to test. Use benign markers and your own browser session. If you can't name the authorization, stop.

The loop

1. Enumerate client-side sources and sinks. List where the page reads attacker-influenceable input in the browser (the URL and its fragment, message data, referrer, storage, the DOM itself) and where it writes to a dangerous sink (HTML insertion, script or event execution, navigation, object property assignment). A source reaching a sink without sanitization is the bug.

2. Test DOM-based cross-site scripting. Does any client source flow into a markup or code sink (assigning HTML, writing an attribute that executes, building a handler) without encoding? If a value from the fragment or a message becomes executable in the page, it is DOM XSS, and it fires without the server ever seeing the payload.

3. Test DOM clobbering. Can attacker-injected markup, in a context that allows some HTML but not script, define named elements that shadow the globals or properties the page's script relies on, redirecting logic or supplying a value the script trusts? Look for script that reads a global that markup could define.

4. Test prototype pollution. Can attacker-controlled keys reach a recursive merge, a query or path parser, or an assignment that walks into a base object's prototype, injecting a property every object then inherits? Trace whether a polluted property later reaches a gadget (a sink that reads it) to turn corruption into script execution or a logic bypass.

5. Test cross-window messaging and navigation. Does a message handler act on data without verifying the sender origin, or does client-side routing take a path or target from input that can become an open redirect or a client-side path traversal? An unauthenticated message handler that writes to a sink is an injection channel from any window.

6. Test cross-origin leaks and record. Can another origin infer state (whether you are logged in, a value) from an observable side channel the page exposes? Rate by impact: script execution and account actions are high; a pure information leak is lower. Record confirmed source-to-sink flows and inputs proven encoded or origin-checked (killed) in the schema.

Why the server never sees it

• The taint stays in the browser. A fragment-to-sink flow leaves no server request, so server-side testing and logs miss it entirely.
• Some sinks are not obvious. An assigned property, a defined named element, or a merged key can be as dangerous as writing markup.
• Origin is the client-side boundary. A message handler without an origin check trusts every window.
• Encoding is context-specific. The right defense depends on the exact sink; the wrong encoder is no defense.

Worked example (a confirm and a kill)

Confirm. A single-page app reads a value from the URL fragment and assigns it into an element's HTML to render a section label, with no encoding. A crafted fragment injects a markup payload that executes in the page. The server never receives the fragment. Confirmed DOM-based XSS, high, remediation = write the value as text or encode for the HTML context, never assign untrusted input as markup.

Kill. A message handler verifies the sender origin against an allowlist before acting, all client sources are written to sinks as text through a context-correct encoder, object merges reject prototype-walking keys, and routing matches paths against a fixed table. Injected fragments, messages, and keys reach no executable or logic sink. Killed, kill_reason = "origin-checked messaging, text-only encoded sinks, prototype-safe merges, table-matched routing; no client source reaches a dangerous sink."

Rationalizations to reject

• "The server sanitizes input." → Irrelevant; the payload never reaches the server. The sink is in the browser.
• "It's just a URL fragment." → The fragment is attacker-controlled and readable by script. It is a taint source.
• "We only merge trusted objects." → If any key is attacker-influenceable, the merge can pollute the prototype. Check the keys.
• "The message came from our own page." → Only if you verified the origin. Without that check, any window can send it.

Executing this in practice

You need to trace taint inside the page, from client sources to client sinks, and to influence those sources (fragment, message, markup, storage) while observing the sink. Browser tooling and client-side dataflow tracing are enough; the source-to-sink map inside the browser is the method.

Related

• adjudicating-taint-paths - the same source-to-sink discipline, applied inside the browser.
• testing-llm-insecure-output-handling - a rendered sink that trusts untrusted content, on the output side.
• FINDING-SCHEMA.md - source = the client-side input (fragment, message, markup, key), sink = the browser execution or corrupted object it reaches.