DOM-based XSS occurs when malicious scripts are executed through client-side JavaScript that modifies the DOM in an unsafe way. Unlike traditional XSS, these attacks don't need to interact with the server. They typically exploit vulnerable JavaScript that processes data from unsafe sources like URL parameters. Prevention requires careful handling of user input in client-side code and proper output encoding.
DOM-based cross-site scripting is a client-side flaw where the vulnerability lives entirely in the page's JavaScript rather than in the server response. The page reads data from a source the attacker can influence, commonly the URL fragment (location.hash), the query string, document.referrer, or web storage, and passes it into a dangerous sink such as innerHTML, the document write method, or eval without sanitizing it. The browser then parses the attacker's data as markup or code and runs it. Because the tainted value may never leave the browser, the payload can sit after the hash in a URL, which servers do not receive, so the server never sees the attack and cannot log or filter it.
DOM XSS grants the same in-origin powers as other XSS: reading tokens and page data, forging requests, and rewriting the interface, all under the site's trusted origin. It is easy to miss because server-side defenses, web application firewalls, and request logging do not apply to data that stays in the browser or hides in the URL fragment. Modern single-page applications are especially exposed, since routing, templating, and rendering all happen client-side and pull heavily from URL and storage values. As frameworks push more logic into the browser, DOM-based sinks multiply, and one unsafe assignment to innerHTML in a widely used component can expose every page that renders it.
Prevent DOM XSS by keeping untrusted data out of dangerous sinks: prefer textContent over innerHTML, avoid eval and legacy document-writing methods, and route any HTML you must insert through a trusted sanitizer or the browser's Sanitizer API and Trusted Types. Framework data binding and a Content Security Policy reduce the remaining surface. cside does not rewrite your application's DOM logic, but it does watch what executes in the browser at runtime. Its Script method analyses third-party script payloads, can block malicious behaviour, and records what actually ran, so an injected or compromised script attempting exfiltration is caught by behaviour rather than by source, and that evidence supports PCI DSS 6.4.3 and 11.6.1.
In reflected XSS the server injects the payload into the HTML it returns. In DOM-based XSS the server response is clean, and the flaw is in client-side JavaScript that reads an attacker-controlled value and writes it into a dangerous sink. The exploit can live in the URL fragment, which the server never receives.
Because the payload often never reaches the server. Values placed after the hash in a URL stay in the browser, and other sources like local storage or the referrer are processed purely client-side. A firewall only inspects traffic it sees, so it is blind to attacks executed entirely within the DOM.
We answer client-side security questions every day. Bring yours.