The Most Common Types of Cyberattacks #6 - Cross-site Scripting XSS Attacks

A cross-site scripting attack, also known as XSS, is one of the most common web app vulnerabilities that has been around since the early days of the World Wide Web.

In this type of malware attack, an attacker exploits the interaction between users and a vulnerable application to inject malicious scripts into web applications. They will dupe the browser into executing malicious scripts in the context of the domain of a victim.

Common methods utilized in this attack include stealing the domain's cookies, modifying or deleting its contents, and engaging in other illicit activities.

What is Cross-site Scripting?

Usually, XSS vulnerability occurs when there are untreated inputs and bad cookie usage. Let us take a case scenario of what happened on Myspace:

A MySpace user found an XSS vulnerability on the site and wrote a payload called “Samy Worm”. This payload was a stored XSS, which was first uploaded on his profile. When a user visited his infected profile, then the visitors saw the following text: “but most of all, Samy is my hero.” Meanwhile, the vulnerability managed to replicate itself onto the victim's profile, allowing the "Samy Worm" infection to persist and spread unhindered. The creator had found it funny until his house was surrounded by police, and he was arrested.

The most famous XSS of all time

Samy wasn’t targeted at executing any serious damage, but we have seen the ramifications that can be caused by XSS attacks.

In 2018, for example, British Airways was affected by a breach attributed to XSS. The attack was executed using a technique known as card skimming, where a hacker injects malicious scripts designed to steal sensitive user data via web forms.

Interestingly, XSS vulnerabilities are hitting the biggest businesses around the world harder, including top sites like Facebook and Steam. In 2020, one researcher found an XSS vulnerability affecting the ‘Login with Facebook’ SDK commonly used by other sites to authenticate users. A similar bug had also been found in Gmail.

Facebook and Gmaill were also victims of Cross-site Scripting

Now, an XSS attack will often take two key steps, with the target being the users of the app:

  • An analysis to identify poorly secured sites,
  • Injecting a malicious script to alter the normal behavior of a web app.

The attacker is then able to bypass the same-origin policy designed to separate different websites from each other. The attacker will often impersonate a legit user of the site. They can carry out user actions via impersonation. It gets even worse if the user has escalated privileges; the attack can take full control of the app!

Symptoms of XSS

The variety of attacks based on XSS is countless. Therefore, the number of symptoms is also limitless. However, the most common is inappropriate popup messages.

It’s not a symptom,  but worth mentioning that outdated CMS systems make servers much more vulnerable to cross-site scripting.

Types of XSS

There are different types of XSS attacks, mainly divided into three broad categories:

  • Stored XSS (AKA Persistent or Type I): We’ll talk about this type when the payload has been stored in a database on the server-side. In practice, anyone can trigger this XSS under the right conditions. The MySpace worm in the example was a classic example of this type.
stored xss
This is how stored XSS Works: Source:
  • Reflected XSS (AKA Non-Persistent or Type II): This type immediately runs on the victim’s site, but it won’t be saved anywhere else. This type is often not a serious type, but it can still cause significant damage.
reflected xss
How reflected XSS Works: Source:
  •  DOM-Based XSS (AKA Type-0): This type is a special type of XSS. This incident occurs when the payload can build itself into the DOM. In this case, XSS can manipulate the page's structure without making any changes to the server-side source.
dom-based xss
How DOM-based XSS Works: Source:

Top XSS Attack Statistics

More than a decade after the Myspace scenario, XSS vulnerabilities have become quite prevalent! XSS vulnerabilities are now in the top 10 critical security vulnerabilities affecting businesses.

They affect the vast majority of web applications. For example, more than 50% of the vulnerabilities in websites in 2015 were XSS-related.

According to a 2020 report compiled by the Common Weakness Enumeration (CWE), XSS ranks top among the Most Dangerous Software Weaknesses. 

A report by HackerOne found that XSS flaws accounted for 18% of all reported cybersecurity issues in 2020. In fact, the bounties paid by companies for these bugs rose by 26% compared to 2019.

Common Vulnerabilities & Bounties Paid By Companies, Source: HackerOne

Research has also shown that XSS attacks tend to target the Entertainment industry. A case scenario is an XSS attack on Fortnite, a popular online video game. Through an inactive webpage, the attackers could access the private data of 200 million Fortnite players without needing any login information.

The Finance, Education, IT, Government and the Transport sector are also popular targets. A 2019 Akamai report showed that 75% of attacks on financial services target APIs directly. A total of 50.7M attacks targeting financial services were XSS-related.

How can you defend against XSS Attacks?

The most effective way to block website cyberattacks is at the application layer using a Web Application Firewall (WAF) and to pay attention to user input processing, particularly things like cookie handling.

If you can, use the httpOnly flag to store confidential data (e.g., sessionID). This way, the cookies can’t be read with this flag on the client-side.

We can’t reiterate this enough; ensure you filter all your user input data. Keep an eye on HTML tags, opening and closing signs.

How can BitNinja protect against XSS Attacks?

Our ultimate WAF solution with ModSecurity could be just what you need to solve all of your XSS challenges. The BitNinja WAF 2.0 operates between visitors’ web browsers and your web server.

To keep you secure from the latest threats, we constantly patch new kinds of CMS vulnerabilities by adding new WAF rules to the rulesets. We also include automated false-positive reporting, which allows you to fine-tune the settings if needed, and we guarantee a low false-positive rate with the pre-defined rulesets.

Need a little help to configure the WAF? Contact our ninjas for support, and they will be more than happy to help you.

Prior to enabling all these rules, it is important to remember that doing so can lead to false-positive results when applied to poorly coded webpages. But if you are confident and you know what you are doing, then just go ahead.

Why is it different from other WAF solutions?

  1. Besides the server-based settings, you can set the filtration level and the strictness for each domain.
  2. We are constantly creating new WAF rules to patch the different kinds of zero-day CMS vulnerabilities.
  3. The pre-defined ruleset ensures a very low false-positive rate. False-positive statistics are available for each domain pattern.

Example for cross-site scripting

It is quite easy for an attacker to inject an XSS payload through an untreated input like a GET parameter in a URL or a POST parameter as a form input if you didn’t sanitize angle brackets, single or double quotes and it can infect your HTML or JavaScript code. Take an example using this classic payload:


Single and double quotes can cause XSS vulnerability because these can influence the closing and opening of the expression.

Example for HTML:

<input type="text" name="username" value="john" onfocus=alert(1) autofocus "">

Example for Javascript:


var name = ’john’;alert(1);'';


If your website is vulnerable to XSS, this short JavaScript code will cause an alert pop-up on your site. It means that anyone can run any JavaScript code on your webpage.

In most cases, these payloads run on the client-side, and here is the problem; an attacker can run any JavaScript on a vulnerable page. Among other things, they can steal data and even impersonate the victim!

If the httpOnly flag is not used for cookies on your site, then it means these can be read on the client-side. An attacker can steal session information from cookies with an XSS, giving access to an account - unauthenticated!

Cross-site Scripting (XSS) FAQs

Why are XSS attacks so prevalent?

  • The financial motive is the biggest driver of XSS attacks. Worse are the resources that make it easy for hackers to execute attacks. Some popular examples are XSSMap, XSS-Radar, XSSer, XSSniper, XSStrike, etc.
  • Some bug bounty programs even provide an economic motivation to look for and disclose information on possible vulnerabilities. Many security experts see vulnerability disclosure as a badge of honor.

Can encryption protect a website from XSS attacks?

SSL certificates are by no means a way to protect against XSS attacks. Regardless of whether the client-server traffic is encrypted or not, the web applications will continue to function in the same manner. The only difference is that the attack will take place in an encrypted connection.

What are some of the vulnerabilities in an application that attackers can take advantage of?

  • Allowing unrestricted user input is a significant vulnerability that can result in XSS attacks. However, most websites typically require user interactions, necessitating appropriate security measures. The problem is that you are likely to fail to control their input.
  • Many open-source tech solutions make it possible to have complex interactions between the server and its users. This can be exploited to perform attacks without detection.

What are some of the consequences of cross-site scripting?

  • XSS attacks are one of the easiest ways for attackers to steal users' credentials to a site. Once the attackers have access to sensitive information of the visitors to a vulnerable site, they could perform unauthorized operations like malicious bank transactions.
  • XSS attacks can thus lead to loss of customer trust leading to loss of business. Some breaches are so costly that they can put you out of business.

How do you prevent Stored and Reflected XSS?

  • For starters, it is essential that you do away with dangerous insertion points.
  • Validate output by only using untrusted data for display. 
  •  Be extremely strict about validating inputs.

How do you prevent DOM Based XSS?

  • Again, you ought to validate inputs.
  • Exercise caution when incorporating untrusted data into sensitive client-side actions.
  •  Analyze and use robust client-side JavaScript code.
  • Use BitNinja ServerProtection.

Cross-site Scripting (XSS) attacks are one of the most common issues in cybersecurity and can have serious consequences, such as loss of customer trust. Cybersecurity is not optional anymore. It is a must! If you haven't tried BitNinja yet, don't forget to register for the 7-day free trial! No credit card needed!

Free Trial

We are always happy to help you! If you have any questions, check out our Knowledgebase, feel free to ask at, or you can even reach us on the Dashboard chat!

Let's make the internet a safer place together!


If you have no more queries, 
take the next step and sign up!
Don’t worry, the installation process is quick and straightforward!
AICPA SOC BitNinja Server Security
Privacy Shield BitNinja Server Security
GDPR BitNinja Server Security
CCPA BitNinja Server Security
2024 BitNinja. All Rights reserved.
Hexa BitNinja Server SecurityHexa BitNinja Server Security