DOM XSS in innerHTML sink using source location.search

 DOM-based Cross-Site Scripting (DOM XSS) is a vulnerability that occurs entirely on the client side when a web application takes untrusted input and writes it into the Document Object Model (DOM) in an unsafe way. Unlike reflected or stored XSS, there is no server-side injection involved. Instead, the issue exists in the JavaScript code running in the browser, which makes it harder to detect if you are not actively reviewing frontend logic.

A common source of DOM XSS is location.search, which contains the query string portion of the URL. For example, in a URL like https://example.com/page?search=test, the value ?search=test is accessible through location.search. Since this value is fully controlled by the user, an attacker can modify it to include malicious content. When developers fail to properly validate or sanitize this input, it becomes a reliable entry point for exploitation.

The vulnerability becomes exploitable when this untrusted input is passed into a dangerous sink such as innerHTML. The innerHTML property does not treat content as plain text; instead, it parses and renders it as actual HTML. This means that any HTML tags provided by the user will be interpreted by the browser. If an application does something like element.innerHTML = location.search, it directly injects attacker-controlled HTML into the page context.

Once this happens, an attacker can craft a payload that breaks normal page structure and introduces executable behavior. For example, injecting an image tag with an invalid source can trigger event handlers such as onerror. When the browser attempts to load a broken image, the error event fires, and any JavaScript attached to it will execute. This is how DOM XSS payloads typically achieve execution without needing script tags.

The impact of this vulnerability depends on what the attacker can access in the browser context. In many cases, it can lead to session data exposure, such as cookies, or allow actions to be performed on behalf of the user. Even though modern browsers implement protections like HttpOnly cookies and Content Security Policy (CSP), DOM XSS is still dangerous because it executes within the trusted origin of the application itself.

The root cause of this issue is unsafe handling of untrusted data combined with insecure DOM manipulation. Developers often assume that client-side input is harmless, but any data originating from the URL, user input fields, or external sources should always be treated as untrusted. Using innerHTML without sanitization is one of the most common mistakes that leads to DOM XSS vulnerabilities.

To prevent this class of issues, safer alternatives should be used. Instead of innerHTML, properties like textContent or innerText should be used when inserting user input into the page, as they treat content strictly as text. If HTML rendering is required, proper sanitization libraries should be used to strip or neutralize dangerous elements and attributes. Additionally, developers should explicitly parse and validate URL parameters rather than using them directly.

Overall, DOM XSS demonstrates how client-side logic can become a security risk when trust boundaries are ignored. Understanding how sources like location.search interact with sinks like innerHTML is essential for both security testing and secure development, as this pattern appears frequently in real-world web applications.