Below is a piece of JS code:

if(!(window.location.href.indexOf('?')> -1)){                      
  id= window.location.href.slice(window.location.href.lastIndexOf('/') + 1);    
 location.hash='var/' + id;  

When I tested this code in fortify, I got XSS vulnerability issue - "The method sends unvalidated data to a web browser*".

Could someone please help how to resolve the issue?

  • Your question is not clear, what is the issue about exactly ? – user45139 May 3 '15 at 7:39
  • I am using the mentioned code and getting id value from window.location.href and using this value in location.hash as you can see in code. But I am getting fortify issue at location.hash='var/' + id, how to resolve it? – Nagendra May 3 '15 at 7:43
  • can you force the type of id? – schroeder May 5 '15 at 16:53

There is no XSS in the pasted code. This is only setting the hash of the URL

e.g. https://example.com/foo/1#var/1

using the location object. XSS can only occur when something in an HTML document is set without proper encoding.

Note that this answer is based on the posted code only, and no assumptions are made about where the hash is later used. If the use of the hash gives rise to a vulnerability, the vulnerability lies here than rather with the posted code.

The reason for this is that the application is then processing user input as though it is trusted. If the above code could create a dangerous hash, then an attacker could also create the dangerous hash without using the posted code in exactly the same way as a reflected XSS attack works. e.g. the attacker gets the user to visit a specially crafted URL like


to trigger the attack. It is upto the hash processing code to deal with this, not the code that generates the hash.

  • This isn't strictly true although I think it is more a reflection on the definition of XSS rather than the lack of potential security issues involved in trusting user input. The hash is frequently used (e.g. AngularJS $location) as a means of routing in single-page applications. It is thus feasible, given the requisite logic is in place, that one could manipulate the hash to subvert the intended use of the application. – Arran Schlosberg May 6 '15 at 3:35
  • 1
    @arran In that case the vulnerability lies in the code that processes the hash, not here. – SilverlightFox May 6 '15 at 5:54
  • fair point; agreed. – Arran Schlosberg May 6 '15 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.