Cross Site Scripting XSS Explained: Stored, Reflected and DOM Types
Cross Site Scripting XSS is one of the common web application security problems.
It happens when a website allows attackers to inject scripts into pages viewed by other users.
These scripts run directly inside the browser. May steal data or manipulate the page.
Security research from OWASP shows that Cross Site Scripting XSS is still frequently discovered during web application security testing.
Businesses take this risk seriously because a single vulnerability can affect users.
Security issues like this are commonly identified during professional security testing performed by specialists in web application vulnerability discovery and ethical hacking roles (Web Application Penetration Testing Career: Why Every Company Needs Web Pentesters in 2026).
What Is Cross Site Scripting XSS?
Cross Site Scripting XSS is a security vulnerability where attackers inject JavaScript into a trusted website so it runs in the browser of other users.
The problem occurs when a website accepts user input but does not properly check or sanitize it.
When the page loads the browser treats the injected script as part of the website.
These vulnerabilities are usually discovered during security testing performed by specialists trained to identify web application weaknesses.

Why Cross Site Scripting XSS is dangerous
- Attackers can steal user session cookies
- scripts run inside trusted websites
- Users may be redirected to pages
- Sensitive data may be captured
places where XSS vulnerabilities appear
- Comment sections
- Search boxes
- Login forms
- User profile pages
How Does Cross Site Scripting XSS Work?
Cross Site Scripting XSS works when a website processes user input without proper validation.
The browser executes the injected script when the page loads.
Security studies show that weak input handling is one of the common reasons XSS vulnerabilities appear in web applications.
Typical attack process
- An attacker submits JavaScript into a form or input field.
- The website accepts the input without filtering it.
- A user opens the page.
- The browser executes the code.
What attackers can do using XSS
- Steal login session cookies
- Redirect users to phishing websites
- Modify page content
- Capture keystrokes
Security testers often identify these weaknesses by intercepting and modifying HTTP traffic during testing, a technique demonstrated in practical web traffic interception and vulnerability testing tutorials (Burp Suite for Web Pentesting: Intercepting Requests and Finding Vulnerabilities).
What Is Stored Cross Site Scripting XSS?
Stored Cross Site Scripting XSS occurs when malicious code is saved inside a website database.
The script executes every time a user loads the page.
Security experts consider stored XSS one of the dangerous forms of this vulnerability.
Common locations for stored XSS
- Blog comments
- Forum posts
- Product reviews
- User profile sections
Example scenario
- An attacker submits a comment containing JavaScript.
- The website stores the comment in the database.
- Visitors open the page.
- The script runs automatically in their browser.
What Is Reflected Cross Site Scripting XSS?
Reflected Cross Site Scripting XSS happens when malicious code is sent through a request and immediately reflected in the server response.
The attack requires a user to click a crafted link.
Phishing campaigns often use reflected XSS techniques.
How reflected attacks are delivered
- Phishing emails
- links
- Fake login pages
- Social media messages
Example attack flow
- An attacker creates an URL containing script code.
- The link is sent to victims.
- A user clicks the link.
- The vulnerable website reflects the script in the response page.
What Is DOM Based Cross Site Scripting XSS?
DOM based Cross Site Scripting XSS occurs when malicious input changes the page structure directly in the browser.
The vulnerability exists inside client side JavaScript code.
Developers sometimes create this issue when scripts insert data into the page.

How DOM based XSS works
- JavaScript reads data from the URL.
- The script inserts that data into page content.
- The input is not validated.
- The malicious code executes.
Common sources
- URL fragments
- Dynamic page updates
- Client side scripts
What Are the Differences Between Stored, Reflected and DOM Based Cross Site Scripting XSS?
Stored, Reflected and DOM Based Cross Site Scripting (XSS) are different in how the bad script’s delivered and run.
Knowing these differences helps developers find problems during security checks and real-world web application security testing.
Each type of XSS attack works differently before the bad code gets to the victims browser. Understanding how they work helps developers and security teams find issues fast and fix them correctly.
Stored Cross Site Scripting (XSS)
Stored XSS happens when bad code is saved on the website server. The script is usually stored in a database.
When users visit the page the stored script runs in their browser.
Common examples include:
- Comment sections
- Forum posts
- Product reviews
- User profile pages
Stored XSS is dangerous because it can affect users without them clicking a bad link.
Reflected Cross Site Scripting (XSS)
Reflected XSS occurs when bad code is included in a request and reflected back by the server in the response page.
The script is not saved on the server. Instead it runs when a victim clicks a crafted link.
Attackers often deliver these links through:
- Phishing emails
- login pages
- Social media messages
- Malicious advertisements
Reflected XSS usually targets specific victims rather than large groups of users.
DOM Based Cross Site Scripting (XSS)
DOM Based XSS occurs in the browser when client side JavaScript processes user input incorrectly.
The vulnerability exists in the pages JavaScript code, not the server.
Typical cases include when scripts read data from the URL and insert it directly into the page without validation.
Examples of sources include:
- URL fragments
- Query parameters
- Client side page updates
- Dynamic JavaScript content
Because the attack happens inside the browser it can be harder to detect with traditional server side security checks.
Key differences
- Stored XSS: Script saved in server database. Automatically affects users.
- Reflected XSS: Script delivered through request. Requires user interaction.
- DOM based XSS: Script executes in client side JavaScript. Happens inside the browser.
Impact comparison
- Stored XSS can affect users.
- Reflected XSS depends on phishing links.
- DOM based XSS depends on end code.
How Can Developers Prevent Cross Site Scripting XSS?
Developers can prevent Cross Site Scripting XSS. They do this by checking what users enter and making sure the output is safe. Good coding habits help reduce the risk of someone taking advantage of this.
Applications should treat all user input as data. Any information coming from forms, search fields, URLs, or uploads needs to be checked before the application processes it. Rules for validation help ensure only the right data formats are accepted, which reduces the chances of scripts getting into the system.
Making output safe is another way to protect.
- Before showing user data in the browser developers turn characters into safe text.
- This stops the browser from running injected scripts as code.
Developers can also use Content Security Policy.
- This controls which scripts are allowed to run on a webpage.
- These policies block scripts that are not allowed and reduce the impact of injected code.
JavaScript on the client side should also handle user data with care.
- Avoid putting input directly into the page.
- This is done using methods that change HTML content.
- Safer coding practices help prevent DOM based XSS vulnerabilities.
Regular security testing is also important.
- Many organizations do vulnerability scans and security assessments.
- They do this to find XSS weaknesses early and fix them.
- This is done before attackers can exploit them.
Important prevention methods
- Validate and sanitize user input
- Encode output before displaying it
- Use Content Security Policy
- Avoid DOM manipulation
Security practices used by companies
- Regular security testing
- Automated vulnerability scanning
- Secure development training
Web applications may also face attacks that trick users into unknowingly performing actions on trusted websites, which is explained in how forged requests manipulate authenticated user sessions (CSRF Attacks Explained: How Hackers Make You Click Links).
Key Takeaways
- Cross Site Scripting XSS is a web security vulnerability.
- Attackers inject JavaScript into trusted websites.
- Stored XSS affects users because the script is saved on the server.
- Reflected XSS relies on links.
- DOM based XSS occurs inside client side scripts.
- Secure coding and testing help prevent these vulnerabilities.