DOM-based XSS simply means a cross-site scripting vulnerability that occurs in the DOM (Document Object Model) of your site rather than in HTML. In reflective and stored cross-site scripting attacks, you can see the vulnerability payload in the response page. In DOM-based cross-site scripting, the HTML source code and response of the attack will be exactly the same, i.e. the payload cannot be found in the response. It can only be observed at runtime or by investigating the DOM of the page.
Simple DOM-based cross-site scripting vulnerability example
Imagine the page
document.write("<b>Current URL</b> : " + document.baseURI);
If you send an HTTP request like
document.write to write out whatever you typed in the URL. However, if you look at the source of the page, you won’t see
After such malicious code is executed by page, attackers can exploit this DOM-based cross-site scripting vulnerability to steal cookies from the user’s browser or change the behavior of the web application page with malicious intent.
DOM XSS vulnerabilities are a real threat
Various research and studies identified that up to 50% of websites are vulnerable to DOM-based XSS vulnerabilities. Security researchers have identified DOM-based XSS issues even in the sites and applications of the biggest web companies.
Server-side filters do not matter
One of the biggest differences between DOM-based XSS and reflected or stored XSS vulnerabilities is that DOM-based XSS can never be stopped by server-side filters. The reason is quite simple: anything written after the
# (hash) is never sent to the server.
Due to this design, anything after the hash won’t be sent to the server. This means that no server-side protection in the code will work against DOM-based XSS. As a matter of fact, other types of web protection, such as web application firewalls, or generic framework protections like ASP.NET Request Validation, also will not protect you against DOM-based XSS attacks.
Input and output a.k.a. source and sink
The logic behind the DOM XSS is that an input from the user (source) goes to an execution point (sink). In the previous example our source was
document.baseURI and the sink was
What you need to understand is that DOM XSS will appear when a source that can be controlled by the user is used in a dangerous sink.
Whenever you see this situation, you need to either make the necessary code changes to eliminate the DOM XSS vulnerability or add suitable encoding.
Below is a list of sources and sinks which are typically targeted in DOM XSS attacks. Note that this is not a complete list, but you get the idea: anything that can be controlled by an attacker is a source and anything that can lead to script execution is a sink.
- HTML Modification sinks
- HTML modification to behaviour change
(element).src(in certain elements)
- Execution Related sinks
Fixing DOM cross-site scripting vulnerabilities
The best way to fix DOM based cross-site scripting and improve web application security is to use the right output method (sink). For example, if you want to use user input to write into a
<div> element, don’t use
innerHtml, but instead use
textContent. This will solve the problem and is the correct way to remediate DOM-based XSS vulnerabilities.
It is always a bad idea to use a user-controlled input in dangerous sources such as
eval. 99% of the time, it is an indication of bad or lazy programming practice, so simply don’t do it instead of trying to sanitize the input later.
Finally, to fix the problem in our initial code example, instead of trying to encode the output correctly, which is a hassle and can easily go wrong, we would simply use
element.textContent to write in some content like this:
<b>Current URL:</b> <span id="contentholder"></span>
document.getElementById("contentholder").textContent = document.baseURI;
This example does the same thing, but this time it is not vulnerable to DOM-based cross-site scripting vulnerabilities.
Vulnerability classification and severity table
|Classification||ID / Severity|