I just pushed an initial commit for a module that can help module developers and site owners test for XSS vulnerabilities: https://www.drupal.org/sandbox/matthew.donadio/2319347
The module does a form alter to add two buttons to forms. The buttons will prefill inputs and textareas with simple XSS, <script>alert('XSS')</script>, for testing purposes. The actual alert message will contain the $form_id and the element name in the message.
I wrote this after I found a bunch of project review applications that all has XSS problems. Sometimes these are easy to spot, but tracing out input-to-output can be tricky sometimes. In addition to a visual on the code, I will often spin up the module on simplytest.me and try XSS on the forms. So, in other words this saves me typing out all of the alerts and also helps pinpoint which form/element has the problem.
The module should properly set X-XSS-Protection to allow alerts in browsers that will prevent them in the direct POST response.
A Drupal 8 version will follow soon, and I may also do a Drupal 6 version.
Comments and complaints welcome.

Comments
Awesome - thanks for
Awesome - thanks for sharing!
The ideal tool would be fully automated and not require a person to click a button, but this is a great start for someone who is going to be manually testing a module anyway :)
knaddison blog | Morris Animal Foundation
Great - automatic
Great if we will get the automated module soon to check the XSS vulnerabilities :)
I will check the sandbox code on my website and provide with its result soon.
Naveen Valecha
https://www.valechatech.net
I thought a little while
I thought a little while about an automated version.
The detection side would be mostly easy. The module would have to clone drupal_deliver_html_page() to examine the page output from drupal_render_page($page_callback_result) for the test injections, and then log them somewhere. The module would then need to hook_page_delivery_callback_alter() this callback in. As far as I can tell, this is the only generic way to do the detection on rendered output. I may do this anyway.
The problem was how to do the automatic injections in a generic manner. The module could unshift a validation function which recurses through the form and does form_set_value() to do the actual injections. However, some modules will validate input instead of plaining the output, so in normal circumstances are XSS safe (whether this is a good idea is a subject for another thread...). However, I don't see how to allow validation to actually happen and let users override the injections to get forms to validate. The module could do this as the last validator, but this may introduce bugs that rely on the validated values.
I think you're working on
I think you're working on this from too far inside Drupal.
Here's how I think an automated system would work:
knaddison blog | Morris Animal Foundation
How would you get past form
How would you get past form validation with this method? For example, field 1 is a required textfield that only allows numeric input, but field 2 is a textfield that is XSS prone. I don't see how a spider would work in this case, which would really reduce the test coverage.
A Drupal-aware spider could
A Drupal-aware spider could look at the field type to know.
If the site makes heavy use of html5 you could figure it out based on the field information.
I agree it's not trivial or a silver-bullet, but I think it has value.
knaddison blog | Morris Animal Foundation
I wonder if you could use
I wonder if you could use phantom.js or another headless browser that runs JS?
In that regard - would a JS console log event be easier to detect than an alert?
Also, there are some additional common vectors (e.g. add " or ' to try to break out of attributes)
No time to elaborate, but I
No time to elaborate, but I think zap (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) could be scripted to do this.