# Ontology for Cross-Site-Scripting (XSS) Attack in Cybersecurity
## 2 Different Types of XSS and Procedures to Detect If a Web Application Is Vulnerable to This Attack  
The best way to know if your web application is secure against XSS attack is to test it. After testing, it is necessary to determine your coding and implementing tools to prevent XSS attacks to your website. Firstly, there exist three main types of XSS attacks:  
(1) Stored XSS attack (also known as Persistent XSS attack, the most dangerous one), which results from malicious payloads which are stored and stay in the database of the web application. The attack is described in Figure 1[9]. For example:  
A \"search\" field where a user can input a JavaScript/HTML code in search text box, \"Login, Registration, Comments etc.\" At least one of these cases should be present in one of the web pages of that website. Here we have a scenario: the adversary usually injects their codes or simply their payloads in the \"Comment\" field of a target website. Automatically by pressing \"Enter\", or clicking \"Submit\" button, their comment gets published, and other users can see it. So their post gets stored in the database, and/or in the \"file system, or other object\" of that website which he posts on. Thus, any click-view of that data launches the vulnerability exploitation, which means the referenced user is attacked.  
Figure 1: Stored XSS Attack.  
Brief explanation:  
* The attacker posts their comments (malicious JavaScript payload) onto a blog site, for example. When a user navigates on that particular website, he gets served with the malicious code snippet of the attacker as a part of the original web page (of that blog).
* Thus, unknowingly, while the victim (our user) visits the site, he is at risk of running that code. This is where the \"sanitization, user-input validation\" comes into play with the top importance. _<script>document.location=[[https://attacker.com/cookie=](https://attacker.com/cookie=)]([https://attacker.com/cookie=](https://attacker.com/cookie=))'+encodeURI Component(document.cookie)</script>_[10].  
(2) Reflected XSS attack, commonly called \"Non-persistent XSS attack\", is the most common one, although it is not the most dangerous one. Basically, the attacker crafts a malicious link, sends it to several desired victims via email, and entices them to click on the link--where the attacker captures victims' browsers. A clever hacker usually makes that malicious link either obfuscated or shortened.  
There is also \"Self XSS\" attack. While the Reflected XSS attack is triggered by sending a link to a targeted person with inputs which are reflected to the browser, there is no link involved in the Self XSS - that is why in this case the \"Reflected XSS\" attack is referred to as the \"Self XSS\" attack.  
(3) DOM Based XSS attack, also called \"Type-0 XSS attack\" could be regarded as a special type of the Reflected attack. Both are triggered by sending a link to a target person with inputs which are reflected to the browser. According to [PERSON] et al., a DOM based XSS attack (Document Object Model) requires special attention because of its nature. The big difference between the Reflected XSS and DOM-based XSS attacks is that the payload of the DOM never reaches the server-side. It will only execute on the client-side (browser).