DOM XSS: Why Server-Side Sanitization Isn't Enough

DOM XSS: Why Server-Side Sanitization Isn't Enough You've sanitized your inputs on the server. You're using parameterized queries. Your Content-Security-Policy is solid. You feel pretty good about your app's XSS posture. Then someone submits a DOM XSS report and gets paid. DOM-based XSS is the variant most devs underestimate — not because it's exotic, but because it never touches your server. Your backend never sees the malicious payload. Your logs are clean. Your WAF didn't fire. And yet JavaScript is executing in your user's browser. Here's how it works and how to find it. Server-Side vs. DOM XSS: The Core Difference In reflected XSS , the payload goes to the server, the server echoes it back in the HTML response, and the browser renders it. Your sanitization on the server stops this. In DOM XSS , the payload never reaches the server at all. It goes directly from a browser-controlled source (URL, fragment, localStorage ) into a dangerous sink ( .innerHTML , eval() , document.write()