Cross-Site Scripting (XSS) is one of the most common — and dangerous — web application vulnerabilities. It allows attackers to inject malicious scripts into web pages viewed by other users, potentially leading to data theft, session hijacking, or unauthorized actions on behalf of users.
In this post, we’ll look at the three major types of XSS attacks with real-world examples, and how the open-source SafeLine WAF helps block them effectively.
What Is XSS?
XSS (Cross-Site Scripting) attacks exploit websites that don’t properly sanitize user input. By injecting malicious scripts into otherwise trusted pages, attackers can:
- Steal cookies or session tokens
- Redirect users to phishing pages
- Alter site content or behavior
Common Types of XSS Attacks
1. Stored XSS (Persistent XSS)
Stored XSS happens when malicious scripts are permanently stored on the target server — for example, in a database — and later served to users.
Example:
An attacker posts this comment on a social media platform:
<script>alert('Your session has expired, please re-login');</script>
When another user views that comment, the script runs in their browser, potentially stealing session data or cookies.
This kind of attack persists until the malicious content is manually removed or the vulnerability is patched.
2. Reflected XSS
In reflected XSS, the malicious script is embedded in a URL and executed when a user clicks it. The server “reflects” the script back in its response without storing it.
Example:
A phishing email contains this link:
https://example.com/search?q=<script>alert('You have been hacked!');</script>
If the server reflects the q parameter directly into the HTML page without escaping it, the script runs immediately upon page load.
While not stored on the server, this attack can still hijack sessions or steal credentials in one click.
3. DOM-Based XSS
DOM-based XSS is triggered entirely on the client side. The vulnerability exists in the JavaScript code that reads user input (e.g., from the URL) and writes it to the page without sanitization.
Example:
https://exampleforum.com?search=<script>document.cookie</script>
If the page’s JS script inserts the search parameter into the DOM without escaping, the attacker can read cookies or manipulate the page content.
This kind of XSS bypasses server-side filters entirely by manipulating the browser-side logic.
How SafeLine WAF Defends Against XSS
SafeLine WAF is a free and open-source Web Application Firewall designed to protect web apps from XSS and other web-based threats. It’s built with developers in mind and supports fast deployment via Docker.
Key XSS Defense Features
Input Filtering
SafeLine inspects and sanitizes all user inputs — blocking scripts, unsafe characters, and common XSS payloads before they reach your application.Output Escaping
User-generated content is automatically escaped during output, preventing scripts from executing in the browser even if they make it through.Real-Time Detection & Blocking
SafeLine uses built-in rules and behavior analysis to detect suspicious requests and block them instantly. It also logs incidents for auditing.
XSS Protection in Action
Let’s say your e-commerce site has a search bar, and an attacker inputs:
<script>alert('XSS!');</script>
If your app reflects the input in the results page without escaping, it will trigger the alert and potentially leak user info.
With SafeLine WAF:
- The script is filtered at the request layer.
- Dangerous output is escaped before rendering.
- The attempt is logged and blocked in real time.
Final Thoughts
XSS attacks are easy to overlook but devastating if exploited. Whether it’s persistent, reflected, or DOM-based, SafeLine WAF provides solid protection for your application right out of the box.
If you're building or running a web app, don’t wait for the next attack — deploy SafeLine today and keep your users safe.