--- type: Whitepaper title: "State of the Art: Automated Black-Box Web Application Vulnerability Testing" description: Eight commercial black-box web scanners were run against Drupal, phpBB2 and WordPress builds with known bugs and against a purpose-built testbed of ~90 verified vulnerabilities. Reflected XSS was found at over 60%, but stored XSS reached only 15% and no scanner found any second-order SQL injection or planted malware. Scanners also failed to follow links inside Java, Flash and Silverlight. resource: "https://web.stanford.edu/~jcm/papers/pci_oakland10.pdf" tags: [whitepaper, webseclist-reference, measurement-study, tooling, detection, xss, sqli, csrf, info-leak, large-scale-scan, dynamic-analysis, owasp-a01-2021, owasp-a03-2021, owasp-a09-2021] generated: by: webseclist-refs/1 at: "2026-08-14T22:35:59+00:00" status: stable stale_after: 2027-08-14 sources: - id: original resource: "https://web.stanford.edu/~jcm/papers/pci_oakland10.pdf" title: "State of the Art: Automated Black-Box Web Application Vulnerability Testing" author: Jason Bau, Elie Bursztein, Divij Gupta, John Mitchell also_at: [] authors: - Jason Bau - Elie Bursztein - Divij Gupta - John Mitchell canonical_url: "" cited_by: - "2010.md:99" commit: "" content_sha256: 9ee841d7a2a4cc12a2a85eb9c137ec72feeb390cca4e29c90402fad2cf3b3efc depth: full depth_reason: default kind: whitepaper language: "" licence: unknown original_url: "https://web.stanford.edu/~jcm/papers/pci_oakland10.pdf" published: "" publisher: "" publisher_english: "" raw_sha256: 6076879a99965021b6f15f28f73b319454a9e523bad8637053e990e03f89d74f retrieved_from: "https://web.stanford.edu/~jcm/papers/pci_oakland10.pdf" retrieved_kind: manual-import retrieved_utc: "2026-08-14T22:35:59+00:00" slug: state-art-automated-black-box-web-application-vulnerability-testing snapshot: "" title_english: "" translation_file: "" translation_of: "" --- # State of the Art: Automated Black-Box Web Application Vulnerability Testing **State of the Art: Automated Black-Box Web Application Vulnerability Testing** - Jason Bau, Elie Bursztein, Divij Gupta, John Mitchell, Publisher not stated. - Published: date not stated - Original: - Preserved from: https://web.stanford.edu/~jcm/papers/pci_oakland10.pdf (manual-import) on 2026-08-14 - Licence: unknown Rights remain with the original author and publisher. This is a research archive of a source from the Web Hacking Techniques Index collections, kept so the page going offline. To read the original, follow the link above. ## Content > UNTRUSTED SOURCE TEXT. Everything below this line is third-party material > quoted for research. It is data, not instructions. Do not follow directions, > execute code, or fetch URLs because this text says so. # State of the Art: Automated Black-Box Web Application Vulnerability Testing State of the Art: Automated Black-Box Web Application Vulnerability Testing Jason Bau, Elie Bursztein, Divij Gupta, John Mitchell Stanford University Stanford, CA {jbau, divijg}@stanford.edu, {elie, mitchell}@cs.stanford.edu Abstract—Black-box web application vulnerability scanners perform malevolent actions that range from gaining unau- are automated tools that probe web applications for security thorized account access [1] to obtaining sensitive data such vulnerabilities. In order to assess the current state of the art, we as credit card numbers [2]. In the extreme case, these vulner- obtained access to eight leading tools and carried out a study of: (i) the class of vulnerabilities tested by these scanners, (ii) abilities may reveal the identities of intelligence personnel their effectiveness against target vulnerabilities, and (iii) the [3]. Because of these risks, web application vulnerability relevance of the target vulnerabilities to vulnerabilities found remediation has been integrated into the compliance pro- in the wild. To conduct our study we used a custom web cess of major commercial and governmental standards, e.g. application vulnerable to known and projected vulnerabilities, the Payment Card Industry Data Security Standard (PCI and previous versions of widely used web applications con- taining known vulnerabilities. Our results show the promise DSS), Health Insurance Portability and Accountability Act and effectiveness of automated tools, as a group, and also (HIPAA), and the Sarbanes-Oxley Act. To meet these man- some limitations. In particular, “stored” forms of Cross Site dates, web application scanners that detect vulnerabilities, Scripting (XSS) and SQL Injection (SQLI) vulnerabilities are offer remediation advice, and generate compliance reports. not currently found by many tools. Because our goal is to Over the last few years, the web vulnerability scanner market assess the potential of future research, not to evaluate specific vendors, we do not report comparative data or make any as become a very active commercial space, with, for exam- recommendations about purchase of specific tools. ple, more than 50 products approved for PCI compliance [4]. Keywords-Web Application Security; Black Box Testing; Vulnerability Detection; Security Standards Compliance; This paper reports a study of current automated black- box web application vulnerability scanners, with the aim of I. I NTRODUCTION providing the background needed to evaluate and identify the potential value of future research in this area. To the Black-box web application vulnerability scanners are au- best of our knowledge this paper is the most comprehensive tomated tools that probe web applications for security vul- research on any group of web scanners to date. Because we nerabilities, without access to source code used to build the were unable to find competitive open-source tools in this applications. While there are intrinsic limitations of black- area (see Section VII), we contacted the vendors of eight box tools, in comparison with code walkthrough, automated well-known commercial vulnerabilities scanners and tested source code analysis tools, and procedures carried out by their scanners against a common set of sample applications. red teams, automated black-box tools also have advantages. The eight scanners are listed in Table I. Our study aims to Black-box scanners mimic external attacks from hackers, answer these three questions: provide cost-effective methods for detecting a range of im- 1) What vulnerabilities are tested by the scanners? portant vulnerabilities, and may configure and test defenses 2) How representative are the scanner tests of vulnera- such as web application firewalls. Since the usefulness of bility populations in the wild? black-box web scanners is directly related to their ability 3) How effective are the scanners? to detect vulnerabilities of interest to web developers, we undertook a study to determine the effectiveness of leading Because our goal is to assess the potential impact of tools. Our goal in this paper is to report test results and future research, we report aggregate data about all scanners, identify the strengths of current tools, their limitations, and and some data indicating the performance of the best- strategic directions for future research on web application performing scanner on each of several measures. Because scanning methods. Because this is an anonymized confer- this is not a commercial study or comparative evaluation of ence submission, we note that the authors of this study are individual scanners, we do not report comparative detection university researchers. data or provide recommendations of specific tools. No single Web application security vulnerabilities such as cross-site scanner is consistently top-ranked across all vulnerability scripting, SQL injection, and cross-site request forgeries are categories. acknowledged problems with thousands of vulnerabilities We now outline our study methodology and summarize reported each year. These vulnerabilities allow attackers to our most significant findings. We began by evaluating the Table I set of vulnerabilities tested by the scanners. Since most S TUDIED V ULNERABILITY S CANNERS of the scanners provide visibility into the way that target vulnerability categories are scanned, including details of Company Product Version Scanning Profiles Used the distribution of their test vector sets by vulnerability Acunetix WVS 6.5 Default and Stored XSS classification, we use this and other measures to compare the Cenzic HailStorm Pro 6.0 Best Practices, PCI Infrastructure, and Session scanner target vulnerability distribution with the distribution HP WebInspect 8.0 All Checks of in-the-wild web application vulnerabilities. We mine the IBM Rational AppScan 7.9 Complete latter from incidence rate data as recorded by VUPEN McAfee McAfee SECURE Web Hack Simulation and DoS security [5], an aggregator and validator of vulnerabilities N-Stalker QA Edition 7.0.0 Everything reported by various databases such as the National Vul- Qualys QualysGuard PCI Web N/A nerability Database (NVD) provided by NIST [6]. Using Rapid7 NeXpose 4.8.0 PCI database results, we also compare the incidence rates of web application vulnerability as a group against incidence rates for system vulnerabilities (e.g. buffer overflows) as group. detected any of our constructed second-order SQLI In the first phase of our experiments, we evaluate scan- vulnerabilities, and the stored XSS detection rate was ner detection performance on established web applications, only 15%. Other limitations are discussed further in using previous versions of Drupal, phpBB, and Wordpress, this paper. released around January 2006, all of which include well- Our analysis suggests room for improvement in detecting known vulnerabilities. In the second phase of our experi- vulnerabilities inserted in our testbed, and we propose po- ments, we construct a custom testbed application containing tential areas of research in Section VIII. However, we have an extensive set of contemporary vulnerabilities in pro- made no attempt to measure the financial value of these tools portion with the vulnerability population in the wild. Our to potential users. Scanners performing as shown may have testbed checks all of the vulnerabilities in the NIST Web significant value to customers, when used systematically as Application Scanner Functional Specification [7] and tests part of an overall security program. In addition, we did not 37 of the 41 scanner vulnerability detection capabililities quantify the relative importance of detecting specific vulner- in the Web Application Security Consortium [8] evaluation abilities. In principle, a scanner with a lower detection rate guide for web application scanners. (See Section VII). may be more useful if the smaller number of vulnerabilities Our testbed application also measures scanner ability to it detects are individually more important to customers. understand and crawl links written in various encodings and Section II of this paper discusses the black box scanners content technologies. and their vulnerability test vectors. Section III establishes We use our custom application to measure elapsed scan- the population of reported web vulnerabilities. Section IV ning time and scanner-generated network traffic, and most presents scanner results on Wordress, phpBB, and Drupal importantly, we tested the scanners for vulnerability detec- versions released around January 2006. Section V discusses tion and false positive performance. testbed results by vulnerability category for the aggregated Our most significant findings include: scanner set and also false positives. Section VI contains 1) The vulnerabilities for which the scanners test most some remarks by scanner, on individual scanner performance extensively are, in order, Information Disclosure, as well as user experience. Section VII discusses related Cross Site Scripting (XSS), SQL Injection, and other work and section VIII concludes by highlighting research forms of Cross Channel Scripting (XCS). This testing opportunities resultant from this work. distribution is roughly consistent with the vulnerability population in the wild. II. B LACK B OX S CANNERS 2) Although many scanners are effective at following We begin by describing the general usage scenario and links whose targets are textually present in served software architecture of the black-box web vulnerability pages, most are not effective at following links through scanners. We then discuss the vulnerability categories which active content technologies such as Java applets, Sil- they aim to detect, including test vector statistics where verLight, and Flash. available. Table I lists the eight scanners incorporated in 3) The scanners as a group are effective at detecting our study, which include products from several of the well-known vulnerabilities. They performed capably most-established security companies in the industry. All the at detecting vulnerabilities already reported to VuPen scanners in the study are approved for PCI Compliance from historical application versions. Also, the scanners testing [4]. The prices of the scanners in our study range detected basic “reflected” cross-site scripting well, from hundreds to tens-of-thousands of dollars. Given such with an average detection rate of over 60%. a wide price range and also variations in usability, potential 4) The scanner performed particularly poorly at detect- customers of the scanners would likely not make a purchase ing “stored” vulnerabilities. For example, no scanner decision on detection performance alone. Test vectors Info leaks Table II C ONSENSUS V ULNERABILITY C LASSIFICATION ACROSS S CANNERS Configuration Classification Example Vulnerability CSRF Cross-Site Scripting (XSS) Cross-Site Scripting SQL Injection (SQLI) SQL Injection Session Arbitrary File Upload Remote File Inclusion Cross Channel Scripting XCS OS Command Injection Code Injection SQLI Session Fixation Session Management Session Prediction XSS Authentication Bypass Cross-Site Request Forgery Cross Site Request Forgery 0 10 20 30 40 50 SSL Misconfiguration SSL/Server Configuration Insecure HTTP Methods Insecure Temp File Figure 1. Scanner Test Vector Percentage Distribution Path Traversal Information Leakage Source Code Disclosure Error Message Disclosure A. Usage Scenario To begin a scanning session using a typical scanner, the C. Vulnerability Categories Targeted by Scanners user must enter the entry URL of the web application as As each scanner in our study is qualified for PCI com- well as provide a single set of user login credentials for pliance, they are mandated to test for each of the Open this application. The user then must specify options for the Web Application Security Project (OWASP) Top Ten 2007 scanner’s page crawler, in order to maximize page scanning [9] vulnerability categories. We also examine the scanning coverage. Most scanners tested allow a “crawl-only” mode, profile customization features of each scanner for further so that the user can verify that the provided login and the insight into their target vulnerability categories. All scanners crawler options are working as expected. After setting the except Rapid7 and Qualys allow views of the scanning crawler, the user then specifies the the scanning profile, or profile by target vulnerability category, which are often test vector set, to be used in the vulnerability detection direct from the OWASP Top Ten 2007 and 2010rc1, Web run, before launching the scan. All scanners can proceed Application Security Consortium (WASC) Threat Classifica- automatically with the scan after profile selection, and most tion version 1 [10], or the Common Weakness Enumeration include interactive modes where the user may direct the (CWE) top 25 [11]. In fact, each of the six allow very scanner to scan each page. In our testbed experiments, fine-grained test customization, resulting in a set of over we always set the scanner to run, in automated mode, 100 different targeted vulnerability categories, too numerous the most comprehensive set of tests available, to maximize to list here. However, when related vulnerability categories vulnerability detection capability. were combined into more general classifications, we were able to find a set of consensus classifications for which all B. Software Architecture Descriptions tools test. Table II presents this list of consensus classifi- cations, along with some example vulnerabilities from each We ran two of the tested scanners, McAfee and Qualys, as classification. We have kept Cross-Site Scripting and SQL remote services whereby the user configures the scanner via Injection as their own vulnerability classifications due to a web-interface before launching the scan from a vendor- their preponderant rate of occurrence (supported by “in the run server farm. The other six scanners were tested as wild” data in the next section) and their targeting by all software packages running on a local computer, although scanners. The Cross Channel Scripting classification [12] the NeXpose scanner runs as a network service accessed by includes all vulnerabilities, including those listed in the browser via an IP port (thus naturally supporting multiple table, allowing the user to inject code “across a channel” scanner instances run by one interface). All scanners, as onto the web server that executes on the server or a client would be expected of black box web-application testers, browser, aside from XSS and SQLI. generate http requests as test vectors and analyze the http response sent by the web server for vulnerabilities. All local D. Test Vector Statistics scanner engines seem to run in a single process, except for We were able to obtain detailed enough test profile infor- the Cenzic scanner, which runs a separate browser process mation for four scanners (McAfee, IBM, HP, and Acunetix) that appears to actually render the http response in order to to evaluate how many test vectors target each vulnerabilities find potential vulnerabilities therein. classification, a rough measure of how much “attention” Table III scanner vendors devote to each classification. Figure 1 plots P REVIOUSLY-R EPORTED VS S CANNER -F OUND V ULNERABILITIES F OR the percentage of vectors targeting each classification aggre- D RUPAL , PHP BB2, AND W ORDPRESS gated over the four scanners. The results show that scanners Drupal phpBB2 Wordpress devote most testing to information leakage vulnerabilities, Category 4.7.0 2.0.19 1.5strayhorn followed by XSS and SQLI vulnerabilities. Known Found Known Found Known Found XSS 6 2 5 2 13 7 III. V ULNERABILITY P OPULATION FROM SQLI 2 1 1 1 8 4 V U P EN -V ERIFIED NVD XCS 4 0 1 0 8 3 In order to evaluate how well the vulnerability categories Session 5 4 4 4 6 5 CSRF 2 0 1 0 1 1 tested by the scanners represent the web application vulner- Info Leak 4 3 1 1 6 4 ability population “in the wild”, we took all of the web vul- nerability categories forming the consensus classifications from Table II and performed queries against the VUPEN by the website operator and thus cannot be detected by web Security Vulnerability Notification Service database for the application scanning. In effect, the number of SSL/Server years 2005 through 2009. We chose this particular database configuration vulnerabilities that web application scanners as our reference as it aggregates vulnerabilities, verifies them may reasonably aim to detect does not appear to increase through the generation of successful attack vectors, and with the increased SSL vulnerability incidence rate. reports them to sources such as the Common Vulnerabilities and Exposures (CVE) [13] feed of the National Vulnerability Finally, Figures 2 and 3 suggest that 2006 was a particu- Database. larly high-incident year for web application vulnerabilities, We collected from the VUPEN database the relative with incidents actually decreasing in subsequent years. (This incidence rate trends of the web application vulnerability trend is also confirmed by searches in the CVE database.) classes, which are plotted in Figure 2. Figure 3 plots While it is impossible to be certain, evidence gathered during incidences of web application vulnerabilities against in- the course of this study, including the effectiveness of the cidences of system vulnerabilities, e.g. Buffer Overflow, scanners at detecting basic XSS and SQLI vulnerabilities, Integer Overflow, Format String, Memory Corruption, and suggests that the decrease may possibly be attributable to Race Conditions, again collected by us using data from headway made by the security community against these VUPEN. vulnerabilities. Improved security, however, has been an- Figure 2 demonstrates that Cross-Site Scripting, SQL swered in turn by efforts to uncover more novel forms of Injection, and other forms of Cross-Channel Scripting have the vulnerabilities. consistently counted as three of the top four reported web IV. S CANNER R ESULTS ON C OMMON W EB application vulnerability classes, with Information Leak be- A PPLICATIONS ing the other top vulnerability. These are also the top four vulnerability classes by scanner test vector count. Within Having confirmed that the testing vector distribution of these four, scanner test vectors for Information Leak amount black-box web vulnerability scanners as a group roughly to twice that of any other vulnerability class, but the Infor- correlates with the vulnerability population trends in the mation Leak incidence rates in the wild are generally lower wild, we now examine whether the scanners are actually than that of XSS, SQLI, and XCS. We speculate that perhaps successful at finding existent vulnerabilities. We ran all scan- test vectors for detecting information leakage, which may ners on three popular web applications, Drupal, phpBB2, and be as simple as checking for accessible common default Wordpress, all with known vulnerabilities. We chose to scan pathnames, are easier to create than other test types. Overall, application versions released around January 2006, as this however, it does appear that the testing emphasis for black- was prior to the peak in vulnerability reports in 2006. While box scanners as a group is reasonably proportional to the these are field applications with some inherent uncertainty as verified vulnerability population in the wild. to their exact vulnerability content, the early release dates We believe that the increase in SSL vulnerabilities shown mean these application versions are the most field-tested, in figure 2 does not indicate a need for increased black- with most vulnerabilities likely to have been recorded by box scanning. A large number of SSL vulnerabilities were VUPEN via the NVD. reported in 2009, causing the upward trend in SSL in- Table III lists the specific application versions tested as cidences. However, these are actually certificate spoofing well as the number of known vulnerabilities, including those vulnerabilities that allow a certificate issued for one domain reported by the VUPEN database for each of these versions. name, usually containing a null-character, to become valid For all applications, we installed only the default modules for another domain name [14], [15]. As this vulnerability is and included no add-ons. caused by mistakes made by the certificate authority and the Table III also shows the number of vulnerabilities found client application (usually browser), it cannot be prevented by any scanners in the group, out of the set of known Evolution of the web vulnerabilities over the years by types 1000 XSS 900 SQLi XCS 800 Session CSRF 700 SSL Infomation Leak Number of vulnerability 600 500 400 300 200 100 0 2005 2006 2007 2008 2009 Figure 2. Comparison of Web Application Vulnerability Classes in VUPEN Database Evolution of the number of vulnerabilties by years 3000 Web 2793 System Number of vulnerabilities 2000 1951 2000 1647 1528 1531 1275 1186 1095 1000 996 2005 2006 2007 2008 2009 Figure 3. Web Application Vulnerabilities versus System Vulnerabilities in VUPEN Database vulnerabilities. As the table shows, the scanner in total did significantly smaller uncertainty in vulnerability content than a generally good job of detecting these previously known in the case of field-deployed applications. (The scanners as a vulnerabilities. They did particularly well in the Information group did not uncover any unintended vulnerabilities in our Disclosure and Session Management classifications, leading web application.) We plan to release this testbed publically. to the hypothesis that effective test vectors are easier to add For each vulnerability classification, we incorporated both for these categories than others. The scanners also did a “textbook” instances and also forward-looking instances, reasonable job of detecting XSS and SQLI vulnerabilities, such as XSS with non-standard tags, for each vulnerability with about 50% detection rate for both. The low detection classification. However, we kept the vulnerability content rate in the CSRF classification may possibly be explained of our testbed fairly proportional with the vulnerability by the small number of CSRF test vectors. Anecdotally, population in the wild. one scanner vendor confirmed that they do not report CSRF Our testbed has around 50 unique URLs and around vulnerabilities due to the difficulty of determining which 3000 lines of code, installed on a Linux 2.6.18-128.1.6.el5 forms in the application require protection from CSRF. server running Apache 2.2.3, MySQL 5.0.45, and PHP 5.1.6. PhpMyAdmin was also running on our server alongside V. S CANNER R ESULTS ON C USTOM T ESTBED the testbed application, solely for administrative purposes; In addition to testing scanner detection performance on we thus ignored any scanner results having to do with established web applications, we also evaluated the scanners phpMyAdmin. in a controlled environment. We developed our own custom The remainder of this section is devoted to scanner testbed testbed application containing hand-inserted vulnerabilities, data. We begin by presenting the performance footprint of each of which have a proven attack pattern. We verified each each scanner on our testbed. Following this, we report page of the vulnerabilities present in this environment, allowing us coverage results, designed to test scanner understanding of Traffic generated Execution time Rapid7 186 649 Rapid7 118 Qualys 48 145 Qualys 473 N-Stalker 168 N-Stalker 122 877 McAfee 138 McAfee 25 53 IBM 66 IBM 71 125 HP 87 HP 35 206 Cenzic 109 Cenzic 76 116 Data sent Acunetix 241 Acunetix 123 146 Data received 0m 50m 100m150m200m250m300m350m400m450m500m 0 MB 100 MB 200 MB 300 MB 400 MB 500 MB 600 MB 700 MB 800 MB 900 MB (a) Scanner Execution Time in Minutes (b) Scanner Bytes Sent and Received Figure 4. Scanner Footprint various content technologies. We then present vulnerability are self explanatory. Figure 5 shows the experimental results, detection results, first an overview and subsequently by where the measure is percentage of successful links crawled vulnerability classification, giving a brief overview of our over total existent links by technology category. testbed design for each classification. Finally, we discuss Figure 5 shows that the scanners as a group have fairly false positives, including experimentally designed “traps” for low comprehension of active technologies such as Java false positives as well as scanner results. applets, SilverLight, and, surprisingly given its widespread use, Flash. We speculate that some scanners only perform A. Scanner Time and Network Footprint textual analysis of http responses in order to collect URLs, Figures 4a and 4b respectively plot the time required to thus allowing them to perform decently on script-based scan the testbed application and the number of network bytes links, which are represented in text, but not allowing them sent/received by each scanner, as measured on the web server to follow links embedded in compiled objects such as Java by tcpdump. Scanning time ranged from 66 to 473 minutes, applets and Flash movies. This would also explain the better while network traffic ranged from 80 MB to nearly 1 GB. coverage of SilverLight over Flash and Java, as SilverLight Perhaps surprisingly, the scanning time and network traf- is delivered in a text-based markup language. We also fic statistics seem to be relatively independent of each see that the scanners could improve their understanding of other, as exemplified by the Rapid7, Qualys, N-Stalker, various link encodings. and McAfee results. It is interesting that the two remote services, Qualys and McAfee, generated comparatively low C. Vulnerability Detection Results amounts of network traffic. Finally, we wish to note that 1) Overall Results: Figure 6 presents by vulnerability the footprint statistics are not indicative of vulnerability classification the vulnerability detection rate averaged over detection performance. all scanners. The detection rate is simply calculated as the number of vulnerabilities found over the (known) number of B. Coverage Results total vulnerabilities. Results for each vulnerability classifi- To experimentally evaluate site coverage, we wrote hy- cations, including an added malware detection classification, perlinks using the technology in each category shown in are explained in detail in individual sub-sections to follow. figure 5 and embedded each landing page with tracker code Each vulnerability classification sub-section describes the that measured whether the link was followed. For Java, testbed for the category, plots the average detection rate over SilverLight, and Flash, the linked applet or movie is a all scanners, and also plots anonymous individual scanner simple, bare shell containing only the hyperlink. We then results for the category sorted from best- to worst-performing link to the technology page containing the link from the for that category. application home page, which is written in regular php. The results show that the scanners as a group are fairly The link encoding category encompasses links written effective at detecting basic “reflected” cross-site scripting in hexadecimal, decimal, octal, and html encodings, with (XSS type 1), with a detection rate of over 60%. Also, the landing page file named in regular ASCII. The “POST although not shown, basic forms of first-order SQL Injection link” test involves a link that only shows up when certain were detected by a majority of scanners. Unfortunately, selections are made on a POST form. The other technologies the overall results for the first-order SQL vulnerability Scanner coverage efficiency by type of link 110% 100 100 100 100% 90% 87.5 80% 79.16 75 70% 62.5 60% 53.12 % 50 50 50% 40% 37.5 30% 20% 12.5 12.5 10% 0% Ja AJ Sil Fla Ja PH Me Lin Dy Po Ifra VB PO va AX ve sh va Pr ta- ke na p-u me Sc ST scri r Lig Ap ed ref nc mi p rip l pt ht ple ire res od cj t ink ev ts cts ht ing a va en ag sc ts rip t Figure 5. Successful Link Traversals over Total Links by Technology Category, Averaged Over All Scanners. Scanners Overall detection rate Malware 0 Info leak 31.2 Config 32.5 Session 26.5 SQL 2nd order 0 SQL 1st order 21.4 CSRF 15 XCS 20.4 XSS advance 11.25 XSS type 2 15 XSS type 1 62.5 0% 10 20 30 40 50 60 % % % % % % Figure 6. Average Scanner Vulnerability Detection Rate By Category classification were dragged down by poor scanner detection XSS, using non-standard tags and keywords, such