Reflected XSS and stored XSS are both types of cross-site scripting (XSS) vulnerabilities that can be exploited by attackers to compromise web applications. While they share some similarities, they differ in how the malicious payload is delivered and stored.
Reflected XSS, also known as non-persistent or type 1 XSS, occurs when the malicious payload is embedded in a URL or a form input and then reflected back to the user in the application's response. This type of XSS vulnerability is typically found in search fields, comment sections, or any other input field that is displayed directly to the user. When the user interacts with the vulnerable input, the malicious code is executed in their browser, allowing the attacker to steal sensitive information or perform actions on behalf of the user.
For example, consider a web application that has a search functionality. If an attacker crafts a malicious URL that includes a script tag with a payload, and a user clicks on that URL, the script will be executed in the user's browser. The payload could be designed to steal the user's session cookies, allowing the attacker to impersonate the user and gain unauthorized access to their account.
Stored XSS, also known as persistent or type 2 XSS, occurs when the malicious payload is permanently stored on the target server and then served to users whenever they access a specific page or view certain content. This type of XSS vulnerability is commonly found in user-generated content areas such as forums, comment sections, or messaging systems. The malicious code is stored in the application's database and is displayed to every user who visits the affected page or views the compromised content.
For instance, imagine a web application that allows users to post comments on articles. If an attacker manages to inject a malicious script into a comment, it will be stored in the application's database. Whenever other users access the page containing the compromised comment, the script will be executed in their browsers, potentially leading to the theft of their sensitive information or the compromise of their accounts.
The key difference between reflected XSS and stored XSS lies in how the malicious payload is delivered and stored. In reflected XSS, the payload is embedded in the user's request and reflected back in the application's response, while in stored XSS, the payload is permanently stored on the server and served to multiple users.
To mitigate these vulnerabilities, web application developers should implement proper input validation and output encoding techniques. Input validation should be performed on all user-supplied data to ensure that it conforms to expected formats and does not contain any potentially malicious content. Output encoding should be applied whenever user-supplied data is displayed to prevent the execution of any embedded scripts.
Reflected XSS and stored XSS are two different types of cross-site scripting vulnerabilities. Reflected XSS involves the immediate reflection of a malicious payload in the application's response, while stored XSS involves the persistent storage and subsequent delivery of a malicious payload to multiple users. Both types of XSS vulnerabilities can be mitigated by implementing proper input validation and output encoding techniques.
Other recent questions and answers regarding Examination review:
- How can a web developer mitigate XSS vulnerabilities?
- What is the difference between stored XSS and DOM-based XSS?
- What are the three main types of cross-site scripting (XSS) attacks?

