testing-client-side-dom-vulnerabilities

name	testing-client-side-dom-vulnerabilities
description	Test the vulnerabilities that live entirely in the browser, where the server is never the sink: DOM-based cross-site scripting from client-side sinks, DOM clobbering, prototype pollution that corrupts application logic, unsafe cross-window messaging, client-side path and open-redirect handling, and cross-origin information leaks. Use when reviewing a single-page app, heavy client-side JavaScript, a browser extension, or any code that reads attacker-influenceable input and writes it into the DOM, a sink, or a shared object. The taint never reaches the server.
license	MIT

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.