Manual (reliable) way: Put string containing characters that have special meaning in HTML into some parameter of HTTP request, look for this string in HTTP response (and possibly) in other places where it's rendered. However, this way is very long as all actions like putting inputs into parameters and finding those strings in HTTP responses are performed manually.

Automated (fast) way: Run security scanner like Arachni. But it seems (after looking at code) that it will find vulnerabilities only in usual contexts and won't treat specially CSS values, JS code etc.

So what is a more efficient (fast and reliable) way for finding XSS vulnerabilities? I'm interested in changing manual way into semi-automated to make process faster

  • 1
    security.stackexchange.com/questions/215/… Have a look at this. I think @AviD's answer is pretty spot on.
    – user10211
    Commented Sep 20, 2012 at 9:08
  • @TerryChia Maybe I'm interested in some semi-automated way of those manual checks but not full scanning Commented Sep 20, 2012 at 9:11
  • It really comes down to what you have done so far. Totally untested app/code? Do an automated scan to detect the low hanging fruit and fixed them first. After you have fixed the common problems, do a more in-depth pen test and code review to find the more obscure errors.
    – user10211
    Commented Sep 20, 2012 at 9:19
  • <script>alert(document.cookie);</scirpt> <script>alert('alert msg');</scirpt>
    – user56613
    Commented Sep 29, 2014 at 7:23
  • 1
    You could try my tool XSScrapy. It's a cli XSS spider that runs fast. Detection rates on par with the best commercial scanners according to WAVSEP. DOMinatorPro is probably the best DOM XSS scanner though. github.com/DanMcInerney/xsscrapy Commented Sep 29, 2014 at 10:27

4 Answers 4


In terms of finding a wider range of XSS issues that, from what I've seen, is really scanner dependent (excellent starting point for that here) and none of them will be perfect (i.e. there will always be cases in black-box scanning where a manual tester will find an issue that scanners will miss). Some have a wider range of vectors and techniques than others.

If you're looking to widen out the coverage of automated tools, you could add in grey/white box tools as they can find issues that are harder to locate with a black-box approach. As an example Brakeman for Ruby on Rails applications has detection for XSS issues.

Also other specialist tools as @Tate Hansen mentions above Dominator for DOMXSS issues.

Essentially as with most things in security there is no silver bullet. You can improve automated coverage by combining multiple tools and approaches, although there will be some areas that are still best discovered manually.

  • Thank you for answer! Using what tools this manual activity can/should be automated? I mean generating input strings, inserting them into request parameters, looking for them in responses etc. Do you do all those things manually with each request parameter? Commented Sep 21, 2012 at 8:21
  • 2
    personally I use a combination of burp scanner and manual requests. This is slow but I like the combination of coverage (from the scanner) with manual control (very useful when testing live sites which may have dangerous functionality). you could look at that like I put about the scanner comparison as there's a large number of options with different approaches, it depends on your precise requirements as to which will work best for you. Commented Sep 21, 2012 at 8:53

DOMinator Pro is a great semi-automated tool for identifying DOM XSS.

What is DOMinator?
DOMinator is a Firefox based software for analysis and identification of DOM Based Cross Site Scripting issues (DomXss). It is the first runtime tool which can help security testers to identify DomXss.

How it works?
It uses dynamic runtime tainting model on strings and can trace back taint propagation operations in order to understand if a DomXss vulnerability is actually exploitable.


If you are testing your own app or you are testing an app for which you have the source code, the best way to go about it is a combination of Manual + automated. Try to use a static analysis tool on the source code. It should find you some XSS vulnerabilities (if any). But be aware that there might be several false positives, depending on the tool that you use.

Next, manual testing - Probably the most efficient ( if you know what you're doing). XSS isn't simply about <script>alert('hi')</script> injection into a text box to see if it gets reflected ( or stored). There are a gazillion vectors that you need to check. Use an XSS cheatsheet New XSS cheatsheet? for this purpose. There will be a lot of failed attempts, but injecting something, checking the return HTML page, and repeating this process after changing the vector, will yield results.


Interesting topic.

XSS represents an interesting challenge. Testing with automated tools can be hit or miss. The reason is that there are many potential attacks so the tools will select a few of them to avoid endless scans.

We've found that profiling the parameter before selectively making attacks can dramatically increase accuracy.

The other fun thing to keep in mind is that many modern browsers block many of these attacks which leads to fascinating arguments with developers as to what percentage of browsers an attack has to be exploitable on before you fix it.

You must log in to answer this question.

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