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.