Burp has identified a potential DOM XSS vulnerability:

The application may be vulnerable to DOM-based cross-site scripting. Data is read from window.location.href and passed to the 'setAttribute()' function of a DOM element

In this example, the vulnerable code is like (I can't include the actual original for confidentiality):

var thing = windows.location.href;
element.setAttribute("fill", thing);

The OWASP DOM XSS Cheat Sheet says "JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext within the Execution Context". I'm not quite sure what they mean by execution context.

Doing some quick tests (in Chrome), this is vulnerable:

document.getElementById("bob").setAttribute("onclick", "alert(1)");

But this is not:

document.getElementById("bob").setAttribute("fill", "" onclick="alert(1)");

Given all that, I feel Burp has reported a false positive. But I worry I may have missed something, so further input would be appreciated.

I am only interested if this is exploitable in recent browsers. I'm not interested in "it's not best practice" or "exploitable in IE 4 on a Mac".

  • I think you can use url() for the fill property. Perhaps you can do something malicious with that? How about url(javascript:alert("XSS");)?
    – Anders
    Oct 14, 2016 at 15:59
  • @Anders - Nice idea. I tried just now and it doesn't work in latest Chrome. The Browser Security Handbook says it works in IE6. Maybe that's the basis for Burp raising the issue - but I'd say IE6 is not a modern browser.
    – paj28
    Oct 15, 2016 at 8:54

1 Answer 1


setAttribute() is safe in that it does nothing more than setting the attribute's value. Even by using special characters in the string you cannot inject an additional attribute (as you attempted in your third snippet), let alone escape the HTML tag.

Some attributes are dangerous for some elements. As you demonstrated, on* attributes are vulnerable because they let you specify script event handlers. Similarly, src and srcdoc are dangerous on <iframe> elements, etc.

The technique of injecting JS via url() as proposed by @Anders has worked in the past for CSS attributes but is not possible anymore in major browsers. Back then, a payload such as <rect fill="url('javascript:alert(1)')"/> could have worked. That might also be the reason why Burp flags it as a potential vulnerability. It's not an attack vector in recent browsers, though.

You must log in to answer this question.

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