A cross-site scripting attack generally occurs when an attacker compromises a website by inserting malicious JavaScript code into the client-side input parameters. Figure 1 depicts a comprehensive perspective of the four XSS attack scenarios covered in this paper.

XSS vulnerability exploits [5] the fact that web applications execute scripts in user browsers. If a user tampers with or alters a dynamically generated script, it puts an online application in danger. Although there are four categories of XSS attacks mentioned in this paper, as illustrated in Figure 1, most contemporary web application developers and researchers are familiar with only three of them since they are more common in the research community [6] [7] . Organizations such as the Open Web Application Security Project (OWASP) [1] [8] have recognized these three types of XSS attacks as the most common XSS attack vectors on the web.

Although each of the four categories of attacks takes a somewhat different approach to exploiting web applications, they are still geared toward the same end goal of collecting user account information as generally illustrated in Figure 2.

However, if you’re not familiar with XSS attacks, this should help put things into perspective. As indicated in Figure 1 regarding the four categories of XSS assaults and also displayed in Figure 2 depicting the typical circumstances of XSS attack vector, the following details about the aforementioned categories are explained respectively.

This form of XSS vulnerability is sometimes referred to as a persistent XSS. This is due to the fact that the malicious script is still present on the server after the attack has been completed [9] . During this type of attack, the attacker injects code that has been maliciously written onto the server in such a way that it cannot be removed. As shown in Figure 3, the scenario I used to illustrate a stored XSS attack [10] injected a script tag directly into the Document Object Model (DOM) and subsequently executed a malicious script using JavaScript hypothetically. However, while this is the most popular method of exploiting XSS, it is also the most common approach neutralized by advanced security professionals and security-conscious software developers [11] . A user uploads a malicious XSS script to a database, requested and viewed by other users, resulting in script execution on their systems as described in Figure 3.

A reflected XSS attack, which is also known as a non-persistent attack, is where the attacker generates a URL that injects arbitrary scripts into the target web application [12] . Most publications and academic resources introduce reflected XSS before moving on to stored XSS concepts. I feel that reflected XSS attacks are frequently more difficult for newly inexperienced programmers to discover and exploit than stored XSS attacks [13] .

A stored XSS attack is relatively straightforward to comprehend from a developer’s perspective. The client provides a resource to the server, which is commonly done through the HTTP protocol. The server inserts the requested resource into a database after receiving it from the client. The malicious script will then be executed unintentionally inside the client’s internet browser if other clients later access that resource, as shown in Figure 3.

On the other hand, reflected XSS attacks work like stored XSS attacks but don’t require a database or a server. No server is involved in a reflected XSS attack because the client code is affected directly in the browser, as demonstrated in Figure 4. Web applications can be vulnerable to this type of attack (see Figure 4) because of actions taken by a user that executes an unstored (interconnected) script on the user’s computer.

The DOM-based XSS attack [12] [14] is obviously a client-side attack. The DOM-based XSS attack type is depicted in Figure 5 as the third important classification for XSS attacks.

The implementation of the DOM in different browsers may make some browsers vulnerable, while others may not. Compared to typical reflected or stored XSS attacks (Figure 3 & Figure 4), these XSS attacks require an extensive understanding of the browser’s DOM and JavaScript to be discovered and exploited.

The DOM-based XSS attacks [15] are principally distinct from other types of XSS in that they do not necessitate communication with a server in any way. As a matter of convention, the source is typically a DOM object that can store text, and the sink generally is a DOM API that can execute a script that has been stored as text.

Both the “source” and the “sink” must be present in the browser’s DOM in order for DOM XSS [16] to work because there’s no server involvement. In most cases, the sink is a DOM API that can run a script stored in the source as text. It’s nearly impossible to detect DOM XSS with static analysis tools or other popular scanners because it never touches a server [17] .

Dr. Mario Heiderich unveiled six (6) new mXSS attack sub-classes in his publication [18] . In mXSS attack, the DOM can be avoided entirely by using InnerHTML, which enables automatic changes to be made to the HTML content. mXSS is sometimes referred to as mutated XSS or mutation-based XSS. This is due to the fact that it is difficult to predict and involves recursion. When the HTML script is loaded into the browser’s Document Object Model, the data is mutated, which causes an error. However, the content loaded into the browser’s DOM is mutated to verify that it is error-free and does not include any improper markup. This is accomplished by using the element.innerHTML attribute. The fundamental downside of this form of XSS attack is its ability to circumvent server-side defenses and client-side filters. Figure 6 depicts a potential scenario for mutation-based XSS attacks.

When an external actor injects something that appears safe, as shown in Figure 6, the browser rewrites and modifies it while processing the HTML, resulting in a mutated XSS attack [19] . This makes it incredibly difficult to find and sanitize bugs in application logic. Despite its novelty and widespread misinterpretation, mXSS attacks have been utilized to bypass the most sophisticated XSS filters available. mXSS has been used to circumvent solutions such as DOMPurify [20] , OWASP AntiSamy, and Google Caja, and a large number of popular web apps (especially email clients) have been discovered to be vulnerable [21] [17] . At its foundation, mXSS works by employing filter-safe payloads that mutate into insecure payloads after filtration. All major browsers are vulnerable to mXSS attacks. Developers must understand how browsers handle optimizations and conditional expressions when rendering DOM nodes.

XSS = Cross-Site Scripting;

DOM = Document Object Model;

mXSS = Mutation-Based Cross-Site Scripting;

NVD [23] [24] = National Vulnerability Database;

CVE [25] = Common Vulnerabilities and Exposures;

CWE [26] = Common Weakness Enumeration;

CVSS = Common Vulnerability Scoring System.

The pie charts below illustrate the number of the top 20 Software Development Vulnerabilities based on CWE Name from 2014 to 2022. Over the last nine years, the most frequent report of a cross-site scripting (XSS) vulnerability has been alarmingly received, as shown in Figure 8. I used python Jupiter Notebook [27] to analyze the data.

This section emphasizes most of the standard solutions that can be adopted to significantly reduce the impact of XSS attacks [31] [32] . It emphasizes on describing the XSS mitigation rules that developers can implement to prevent XSS attacks from occurring. It’s evident that these techniques aren’t magic; they’re ineffectual without adequate awareness of users.

It is illustrated from Figure 8 that just two vulnerabilities are dominating the field of web application security attacks, specifically XSS and SQL injection vulnerabilities. Developers can now use numerous preventive measures to keep themselves safe from XSS attacks. Data entered by the user that isn’t trusted is protected using a combination of filtering, escape, and sanitization procedures. The following Table 1 and Table 2 describe each technique:

There are two varieties of escaping: input escaping and output escaping. Practical input escaping requires detecting the context of the untrusted data inserted correctly. In contrast, output escaping is performed to the response web page’s written data. This also considers the data’s context, which is essential for mitigating stored XSS attacks.

The proliferation of XSS vulnerabilities attracts the interest of researchers and developers of security solutions. The variety of XSS attacks that each solution is

designed to defend against has inspired the development of a wide variety of countermeasures. Based on the measures of their implementation model, I have grouped these solutions or techniques into five categories: client-side techniques, server-side techniques, machine learning techniques, and proxy-based techniques. In the following subsections, I have emphasized the most significant and effective methods proposed by the researchers as advantages and observed limitations to those approaches as disadvantages. In the appendix, you can find more information about the researchers’ techniques.