Digging Deep Into Dom XSS


Okay let’s tackle this beast, as i am writing this, i’m trying to prepare you for what’s coming because this will not be easy at all. Burp suite pro makes it somewhat easier but even then, you still need to be able to interpret the scan results and exploit the vulnerability. This is where many hackers will fail. It’s as simple as that, this is not something you do for fun, this is serious business.

Photo by Markus Spiske on Unsplash

What is DOM XSS

To tackle this question we first need to answer what the DOM is. I will not go too deeply into this topic as it can be very complex and goes back to how webpages are built. You are technically not even viewing the DOM if you looking at the source code of a webpage as the DOM goes back one step and describes how a webpage is built up to javascript so that JS can then convert that DOM into objects and manipulate it. To inspect the DOM properly this means that we MUST USE THE DEVELOPER CONSOLE AND NOT INSPECT SOURCE.

DOM Sink

When we talk about DOM sinks, we talk about locations where user controlled data will enter the DOM. There are 3 types of DOM sinks and we will go over all of them.

Document sink

<img src=x onerror=confirm()>

Location sink


Execution Sink


DOM Source

A source is a JavaScript property that accepts data that is potentially attacker-controlled. An example of a source is the location.search property because it reads input from the query string, which is relatively simple for an attacker to control. Ultimately, any property that can be controlled by the attacker is a potential source. This includes the referring URL (exposed by the document.referrer string), the user’s cookies (exposed by the document.cookie string), and web messages.


Testing for DOM XSS

Testing for DOM XSS is not always as simple as testing for source-based XSS. We NEED to use the developer tools to test for this as the values will appear in the DOM, not in the source code.

Testing for document sinks

To test for document sinks we will need to

  • We will then need to open the developer tools and look for every location that our document sink is being referenced.
  • It will look something like this: “var x=document.location”
  • We will then need to look everywhere that our variable x is being used and check if it’s being passed into an HTML sink
  • We can use the debugger that’s built into the developer console for this
  • We will then need to apply our regular HTML XSS routine (see previous chapters and cheat sheet)

Testing for JS execution sinks

Testing for JS execution sinks is a little bit harder. With these sinks it can be that your input does not even appear anywhere within the DOM which makes it impossible to search for. In this case we will need to use the JS debugger to find out if our input is being passed into a sink.

  • When we find out where our value is being read from a source, we can use the debugger to set a breakpoint.
  • Track this variable with the debugger (step next or step over) and see if it is being passed into a DOM sink
  • If the source gets assigned to multiple variables or other variables along the way you will also need to track those variables
  • When we have found our sink, our regular XSS attack strategy comes into play.


So, amazing hacker, you may see that DOM based vulnerabilities are very complex and this is just the beginning of what the DOM has to offer. I hope you enjoyed this tutorial and i wish you a million bugs.

No b*llshit Hacking tutorials with extreme value in short bursts

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store