I was trying my hands at DOM-based XSS. I came across a scenario where a user-controlled string from the URL is included in JavaScript as below.

var userControlled=substring of URL;

The URL is something like http://mydomain/param1=qwerty, where I can enter any value for param1 and the system would not complain.

Note: Value of param1 does not directly appear anywhere in the response, but it is used by DOM.

Or the URL can be http://mydomain/param1=qwerty#sadsdsdsd.

I was just wondering, is there a way to redirect user to a different domain or execute a script or anything which can help me execute a successful XSS attack? Or any other attack for that matter.

  • 2
    Hello Sachin, please give some more details as it is quite of hard to guess, what you are aiming at. DOM means "Document object model" and is basically the hierarchical collection of all the elements and attributes that make up an HTML document. Therefore it is unclear what you mean by something being part of the DOM but not part of the response. Is it written to the DOM by JavaScript code? If yes, what does the code look like? Commented Nov 21, 2011 at 13:16
  • @Hendrik Brummermann♦ don't worry about it man, this js snip isn't vulnerable to dom based xss.
    – rook
    Commented Nov 21, 2011 at 15:33
  • @Rock, that's why I am asking for the relevant parts of the code. Commented Nov 21, 2011 at 17:02
  • I'm not so sure it's not vuln. to XSS (we don't how if the string is properly escaped). I see 3 potential vectors here: (1) get out of string [param1=";alert(1) ] , (2) start new script param1=[/script][script]alert(1)[/script], (3) maybe you can put object instead of string [ param1={valueOf:function(){alert(1)}} ] Commented Nov 22, 2011 at 23:01
  • The question title is very confusing. It sounds like this has nothing to do with the DOM. (However, I can't tell what "used using DOM" means. If the only use of the DOM is setting window.location = ..., then that's not what is usually considered DOM-based XSS.)
    – D.W.
    Commented Nov 23, 2011 at 0:57

4 Answers 4


This snippet of code does not have an XSS flaw but it does suffer from parameter splitting. It allows the user to specify extra GET parameters which can allow escalation of privileges when the request carries credentials such as a CSRF token in an earlier parameter or authorization cookies.

For example, if userControlled is


then the browser will GET /abc/xyz?param=&start-world-war-iii=true with the user's cookies.

It's probably low risk since assigning window.location leads to a GET request which rarely have side-effects that can be abused by the carried credentials.

To mitigate this, userControlled should be normalized:

window.location="/abc/xyz?param=" + encodeURIComponent(userControlled);
  • Good explanation, great solution to fix this. A nitpick: "leads to a GET request which rarely carries credentials" - I suspect you mean "which rarely causes side effects". GET requests often carry credentials, via the cookies that are sent along with GET requests.
    – D.W.
    Commented Nov 23, 2011 at 0:58
  • @D.W. Quite right. Edited. Commented Nov 23, 2011 at 1:23

This snip of JS is not vulnerable to DOM based XSS. I recommend using the DOM Snitch plugin for auditing applications for DOM based XSS.

  • Ok lets leave DOM XSS aside, do you see any thing else that is wrong with this? Commented Nov 22, 2011 at 7:01
  • @Sachin Kumar if window.location was being fully controlled then it would be an invalidated redirect, but as it stands its completely safe.
    – rook
    Commented Nov 22, 2011 at 7:44
  • All downloads for DOM Snitch are marked as deprecated at its site. Can you recommend other methods for finding DOM-based XSS? Commented Sep 4, 2013 at 7:07

While Mike's answer is correct in that the provided example is not vulnerable to DOM-based XSS, his proposed attack is unnecessary as an attacker who can get a user to click his particular link could also just get a user to visit the /abc/xyz?param=&start-world-war-iii=true location directly.

If for example the code looked more like this, it would be vulnerable to DOM-based XSS:

var userControlled = document.location.hash.slice(1);
var s = "<script>document.location='/path/to/thing/" + userControlled + "';<\/script>";

Then there are several things you can do. While it might be immediately obvious to use something like /path/to/target?param=value#alert('xss');' to break the location change while still being able to execute JavaScript, one can also use something like /path/to/target?param=value#'%2b(alert('xss2'),'value')%2b' which will still perform the location change but will also run JavaScript while concatenating together the new location string.


Yes, your sample is exploitable for DOM-based XSS to redirect a user. Here is a sample of a payload:

make_a_js_error;</script><meta http-equiv="refresh" content="0;URL='http://test.com/hack.html" />

We can make a js error on the page to stop regular JS behaviour on the page. Then user can be redirected with meta tag.

Here is a full sample:


$hostMain = '//test.com';

$payload =
make_a_js_error;</script><meta http-equiv="refresh" content="0;URL='http://test.com/hack.html" />
?><!DOCTYPE html>
<html lang="en">
    <meta charset="UTF-8">
    <title>XSS Sample</title>
    <?php if(isset($_GET['param'])):?>
        window.location = "<?php echo $hostMain . '/' . $myFile;?>/?param="+<?php echo urldecode($_GET['param'])?>;
    <?php endif;?>
<a href="<?php echo $hostMain  . '/' . $myFile . "?param="; echo urlencode($payload);?>">do redirect</a>

  • I believe the point is that JavaScript is reading the URL parameter and setting window.location directly. As a result there is no room for escaping. You show the server processing the parameter and sending broken HTML. That would be a standard reflected XSS vulnerabilitiy which the OP said this is not Commented Nov 2, 2018 at 22:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .