I have Burp and Appscan telling me that Reflected XSS is possible due to a particular variable on a particular page.

The following example is given of what Appscan injected


and what Burp injected


I have tried variations on both, with and without quotes, different encoding, and I can never get any javascript to work in any browser. Currently trying chrome with --disable-web-security, which makes no differences.

I can get the code displayed in the source of the page, so I know the vuln is there, but I am having trouble actually validating it.

What is in common, if anything, with what burp and appscan used to validate the vulnerability?

I'd like to understand this better so I can validate easier in the future.

  • Maybe check the developer tools (F12) if there is some JavaScript error preventing execution of the code you are injecting.
    – bretik
    Aug 25, 2014 at 10:54
  • 1
    @SilverlightFox How in the world is a question with specific code examples a duplicate of a question asking about a browser to test with in general? Aug 25, 2014 at 15:57
  • 1
    @SilverlightFox Wow. Not duplicates at all. Again, one is a general question, one is a specific code example. But, OK. Aug 25, 2014 at 16:56
  • 1
    @SilverlightFox Answer wouldn't be the same, any a same answer is not what determines if a question is a duplicate or not. I've been away for a while and that might have changed, do you have a reference for that policy? Aug 25, 2014 at 18:29
  • 1
    It's not a moot point, and the banner on this question is misleading. I am not asking in this question for a browser I can test XSS with, as I already found that with the arguments to chrome, however the XSS was seemingly not working and I wanted to verify it was a false positive, now that I had a browser I can test it. Get it? Aug 26, 2014 at 1:51

2 Answers 2


Appscan has the "show in browser" feature that opens Appscan's special "worst of all worlds" browser for the given vulnerability. If it isn't a false positive, this browser should execute the Javascript. I have found it a pretty reliable way to check for false positives.
enter image description here

For all other testing, I've found that Firefox is the least protected from XSS, so I always use Firefox for hand testing.

It happens a lot that the actual page that executes the XSS is an error page that has been redirected to and maybe you are not allowing your hand-testing to proceed all the way to that error page.

Note that with the Burp example you show, the Javascript will not execute until you actually move the mouse over the control in question.


AppScan and Burp suite reports reflected XSS even when the there is no JavaScript executed. It shows that the response for that particular request consists of the payload added but whether the payload was executed as JavaScript or it took it as plain text it does not show.

You must log in to answer this question.

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