XSS — Cross-Site Scripting
Some attacks target the server.
XSS targets the user. Quietly, invisibly, and often fatally.
It’s not about breaking in.
It’s about slipping past.
Injecting code into places that were never meant to run it.
What this page covers
- What XSS is: the concept, the mechanics, and the impact
- How to exploit it: payloads, vectors, and real-world examples
- How to defend against it: encoding, sanitization, and browser-level protections
- How to detect it: symptoms, patterns, and testing strategies
- How I’ve practiced it: labs, notes, and personal experiments
This isn’t just a list of payloads.
It’s a study of how trust in the browser can be weaponized, and how to take that weapon away.
What XSS Actually Is
Cross-Site Scripting (XSS) is a vulnerability
that allows attackers to inject malicious scripts
into web pages viewed by other users.
These scripts run in the victim’s browser,
often with full access to cookies, session tokens, DOM elements, and more.
The Core Idea:
A web application takes user input
and reflects it back into the page
without proper sanitization or encoding.
That input becomes executable JavaScript,
and the attacker controls what it does.
Types of XSS
| Type | Description | Example |
|---|---|---|
| Reflected XSS | Payload is in the URL or request, reflected immediately | search?q=<script>alert(1)</script> |
| Stored XSS | Payload is saved in the database and shown to others | Comment field with <script> |
| DOM-based XSS | Exploits client-side JavaScript logic | JS reads location.hash and injects it into the page |
Each type has different entry points, but the outcome is the same. Attacker-controlled code runs in the victim’s browser.
What Happens When It’s Exploited
- Session hijacking (stealing cookies or tokens)
- Credential theft (keylogging or fake login forms)
- Defacement (changing page content)
- Malware delivery (via drive-by downloads)
- Browser-based pivoting (attacking internal apps via the user’s browser)
XSS turns the browser into a weapon, and the user into a gateway.
How to Mitigate XSS
Defense is not just one fix. It’s a layered mindset.
1. Output Encoding
Encode user input before rendering it in HTML, JS, or attributes.
Use libraries like OWASP’s ESAPI or built-in framework tools.
2. Input Validation
Reject unexpected input early, especially for fields that shouldn’t contain markup.
3. Content Security Policy (CSP)
Restrict what scripts can run and where they can come from.
Even if XSS is present, CSP can limit its impact.
4. Sanitization
Strip dangerous tags and attributes from user input.
Use trusted libraries like DOMPurify.
5. HTTPOnly Cookies
Prevent JavaScript from accessing sensitive cookies.
6. Mismatching Information
Make sure that Client and Server don't have missmatching information passed to them. Like sanitization on one but not the other, or filtering different things.
Mitigation is about breaking the chain. Stopping input from becoming execution.
How I Practice XSS
I use labs like:
- Hack The Box: Academy and challenges
- PortSwigger Web Security Academy
- TryHackMe: XSS playgrounds
- DVWA and Juice Shop in my homelab
I test:
- Payload variations (<img src=x onerror=alert(1)>, "><script>)
- Contextual escapes (HTML, JS, URL, attributes)
- Bypasses (filter evasion, encoding tricks)
Every failed payload teaches me something. Every successful one shows me how fragile trust can be.
Final Thought
XSS isn’t just a bug.
It’s a lesson in how trust is built, and how it breaks.
It was the first exploit I learned, and it’s still one of the most revealing.
This page is my evolving study of it.
Not just how to trigger it, but how to understand it, defend against it, and explain it clearly.