Subscribe to our Blog

Get the Latest Application Security News and Content

How DOM XSS Attacks work

According to various research and studies, up to 50% of websites are vulnerable to DOM Based XSS vulnerabilities. Security researchers detected DOM XSS issues even in high profile internet companies like Google, Yahoo, and Amazon.

We already covered what DOM XSS attacks are in another blog post. In this blog post, we are going to further explain how DOM XSS attacks work.

Here is a quick reminder before you continue – In DOM XSS attacks, the attack payloads are executed due to modifications of the DOM environment. Because the attack occurs in the victim’s browser, the client-side code executes in a strange or “unexpected” manner.

How do DOM XSS attacks work?

Let’s say we have a code that creates a form. This form lets a user select a timezone. The query string also has a default timezone. It’s defined by the defaulttimezone parameter. The code would look something like this:

Select your Time Zone:


document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>CET</OPTION>");


The “http://www.some.site/page.html?default=CST” URL then invokes the page. Hackers can now send a URL that looks like this 


to launch a DOM-based XSS attack. When an unsuspecting user clicks this link the browser sends a request for /page.html?default=<script>alert(document.cookie)</script> to www.example.site.

What does the server do now? It responds with a page that contains the malicious Javascript code. The browser now creates a DOM object for that page and the document.location object will contain this string:


Where is the problem?

The original Javascript code on this page won’t expect the default parameter to have any HTML markup. Because of this, it will echo it into the DOM during runtime. Any browser will render the resulting page and end up executing the malicious script. (alert(document.cookie)).

Keep in mind that the server’s HTTP response won’t contain the attacker’s payload. The payload will reveal itself in the client-side script at runtime. It happens when the flawed script opens the DOM variable (document.location) while assuming that it isn’t malicious.

With this out of the way, how are DOM-based XSS attacks different than others of this kind? First, the HTML page is static. In the case of other XSS attacks, malicious scripts are put into the source code of the page. Second, the script code doesn’t reach the server when the # character is used. # is seen as a fragment, so the browser won’t forward it. Due to this the server-side attack detection tools won’t detect or identify this kind of attack. Yet, there are cases of some URL types where the payload gets to the server and it is detected.

Common XSS vulnerabilities have completely different characteristics from DOM-based XSS vulnerabilities. Hackers who utilize DOM-based XSS attacks exploit DOM-objects by manipulating them and client-side properties.

Scan your application for DOM-XSS vulnerabilities and thousands of others right now. Sign up for a FREE NeuraLegion account.


The difference between Standard XSS and DOM-based XSS 

What’s the difference between a classic XSS and a DOM-based XSS? Let’s go over the key difference:

The root cause 

The root of both the classic XSS and a DOM-based vulnerability is the source code.


For classic XSS, the premise is the malicious embedding of client-side data by the server in the outbound HTML pages. For DOM-based XSS, it’s the malicious referencing and use of DOM objects in the client-side.

The page type

Classic XSS attacks target dynamic page types. DOM-based XSS attacks can target both static and dynamic page types.

What can detect them

Logs and intrusion detection systems can detect classic XSS attacks. DOM-based XSS can remain unnoticed server-side if the hacker uses evading techniques.

How to identify vulnerabilities

For both classic and DOM-based XSS attacks you use vulnerability detection tools that can perform automatic penetration testing. The code also needs to be reviewed. The only difference is that for classic XSS you do it server-side, while for DOM XSS you do it client-side.

Preventing these vulnerabilities

Intrusion prevention systems and sanitation for the server-side for classic XSS. It’s the same for DOM XSS, but you sanitize the client-side instead of the server-side.

Protect yourself against DOM-based XSS attacks

You cannot detect DOM XSS attacks from the server-side. The malicious payload doesn’t even reach the server in most cases. Due to this, it can’t be sanitized in the server-side code. The root of the issue is in client-side code, the code of the page. 

You’re free to utilize any prevention techniques for DOM XSS that you can use for standard XSS attacks. There’s only one thing you need to pay attention to. For DOM XSS attacks you need to review and sanitize the client-side code instead of the server-side code.

There are a couple of things to keep in mind if you want to prevent DOM XSS attacks. First, refrain from using data that was received from the client for any kind of client-side sensitive actions (redirection or rewriting).

Second, sanitize client-side code. Do this by inspecting references to DOM objects, especially those that pose threat like referrer, URL, location, and so on. This is important in cases where the DOM can be modified.

Third, use intrusion prevention systems. Any that are able to inspect inbound URL parameters and can prevent the serving of inappropriate pages are fit for the job.

These days DOM XSS detection is automated. Have you heard of NexPloit? It’s the world’s very first AI-powered Application Testing Solution that can identify DOM XSS vulnerabilities. It does it all on its own, so you don’t need to lose manpower or finances to deal with DOM XSS vulnerabilities. 

Get the Latest Application Security News and Content


Scale up efforts and set the new standard of integrating security into modern development!