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 a...