Cross-Site Scripting (XSS) is one of the most common and misunderstood web vulnerabilities. Many beginners see it as "just an alert box," but in reality, XSS can lead to serious account compromise and business impact.
This blog explains:
- What XSS really is
- Why it is dangerous
- How it works internally
- Its major types
- And finally, how payloads evolve level by level to demonstrate understanding
What is XSS?
Cross-Site Scripting (XSS) occurs when a web application:
- Takes untrusted user input
- Inserts it into a webpage
- Without proper output encoding
- And the browser executes it as JavaScript
In simple terms:
The website trusts the input, and the browser trusts the website.
That broken trust is XSS.
What Problems Can XSS Cause?
XSS is dangerous because it executes in the victim's browser, not on the server.
This means an attacker can:
- Steal session cookies
- Perform actions as the logged-in user
- Modify page content
- Redirect users to phishing pages
- Bypass client-side security controls
In many real cases, XSS leads directly to account takeover.
How XSS Works (Behind the Scenes)
The flow is always similar:
- Attacker supplies input (URL, form, comment, profile name)
- Application reflects or stores the input
- Browser renders the response
- JavaScript executes in the user's context
Important point:
XSS is not a browser bug. It is a server-side output handling mistake.
Types of XSS (Brief Overview)
1. Reflected XSS
- Payload comes from the request
- Reflected immediately in the response
- Common in search pages and error messages
2. Stored XSS
- Payload stored in database
- Executes whenever any user views the page
- Common in comments, reviews, profile fields
3. DOM-Based XSS
- Happens entirely in the browser
- JavaScript reads data from URL or DOM and writes it unsafely
- No server-side reflection required
Creating XSS Payloads step by step:
Payloads are not about hacking. They are about confirming execution context.
Below is a learning progression — from beginner to intermediate understanding.
Level 1 — Basic Execution Confirmation
Goal: Confirm JavaScript execution
Example:
<script>alert(1)</script>If an alert appears, JavaScript execution is confirmed.
Level 2 — Breaking Out of HTML Context
Goal: Test if input is reflected inside HTML tags or attributes
Example:
"><script>alert(1)</script>This checks whether the application properly escapes quotes.
Level 3 — Event-Based Execution
Goal: Execute JavaScript using HTML events
Example:
<img src=x onerror=alert(1)>Very useful when <script> tags are filtered.
Level 4 — Tag & Filter Bypass Awareness
Goal: Bypass weak filters and restricted tags
Example:
<svg onload=alert(1)>This works because SVG is often overlooked during sanitization.
Level 5 — Context Awareness (DOM-Based Thinking)
Goal: Understand where input is used in JavaScript
Example (URL-based):
#"><img src=x onerror=alert(1)>This is useful when JavaScript reads from location.hash or similar DOM sources.