Cross-Site Scripting (XSS): The 2026 Attack Guide

What Is Cross-Site Scripting (XSS)?

Cross-site scripting is a vulnerability that lets an attacker inject client-side scripts into pages that other people view. The browser cannot tell the injected code apart from the site's own code, so it runs the attacker's JavaScript with the full trust of the site's origin: its cookies, its session, its DOM.

The name is a historical accident. The interesting part is not that scripts cross sites, it is that user input crosses the line from data into executable code. A comment field, a search box, a URL parameter, a username, anything a page later renders without escaping can carry a payload that the browser executes.

XSS maps to CWE-79, and it matters because it runs in the victim's context, not the server's. An attacker who lands XSS on a banking app is not on the server, they are inside your logged-in tab, able to do anything you can do there. That is why it consistently ranks among the highest-volume findings in bug bounty programs.

How an XSS Attack Works: The Root Cause

Every XSS bug has the same origin as SQL injection: the application mixes untrusted input into an output it later interprets. For SQLi the interpreter is the database. For XSS it is the browser, and the language is HTML plus JavaScript.

Here is the mistake in its plainest form. A page echoes a search term straight into the HTML:

<!-- Vulnerable: the query is written into the page unescaped -->
<p>You searched for: <?php echo $_GET['q']; ?></p>

Send q=shoes and the page reads "You searched for: shoes". Send q=<script>alert(1)</script> and the browser does not print those characters, it parses them as a real <script> tag and runs it. The input stopped being text and became part of the page. Nothing in the string told the browser the attacker's tag was meant to be displayed, not executed.

This is why blocklisting fails here just as it does with SQLi. Teams try to strip <script> and attackers reach for <img src=x onerror=alert(1)>, or an svg, or a JavaScript URL, or an event handler on a tag you forgot. The dangerous inputs are effectively infinite because the problem is not the payload, it is that the output was never encoded for the context it landed in.

The Three Types of XSS: Reflected, Stored, and DOM-Based

What are the types of XSS? There are three: reflected XSS, where the payload is bounced back in the immediate response; stored XSS, where the payload is saved on the server and served to every visitor; and DOM-based XSS, where client-side JavaScript writes untrusted data into the page without the server ever seeing the payload. They differ in where the input lives and who gets hit.

Reflected XSS

Reflected XSS takes input from the current request, usually a URL parameter, and writes it straight into the response. The payload is not stored anywhere, so the attack needs a delivery step: the attacker crafts a malicious link and gets a victim to click it. Think of a search page that reflects your query, or an error page that echoes a bad value.

A reflected payload rides in the URL:

https://shop.example/search?q=<script>alert(document.domain)</script>

Anyone who opens that link runs the script in their own session on shop.example. Reflected XSS is the most common variant and the one you will trip over first when testing, because any parameter echoed into a page is a candidate.

Stored XSS

Stored XSS, also called persistent XSS, is the dangerous one. The payload is saved in the application, a comment, a profile bio, a support ticket, a product review, and then served to everyone who views that content. There is no link to send. The victim just loads a normal page and the attacker's script is already there waiting.

Imagine a forum where a post body is rendered without encoding. An attacker posts a comment containing a script, and every user who opens the thread executes it. Stored XSS on a high-traffic page is close to a self-spreading incident, which is exactly how the old Samy worm tore through MySpace in 2005, adding over a million friends in under a day.

DOM-Based XSS

DOM-based XSS never touches the server response. The vulnerable code is JavaScript running in the browser that reads from a source it should not trust, such as location.hash or document.referrer, and passes it to a sink that executes markup, such as innerHTML or document.write.

// Vulnerable: hash is written into the page as HTML
document.getElementById('welcome').innerHTML =
    'Hello, ' + decodeURIComponent(location.hash.slice(1));

Load the page with #<img src=x onerror=alert(1)> and the browser builds that image element and fires the handler. Because the payload lives in the fragment after #, it is often never sent to the server at all, which means server-side filters and many WAFs never see it. As single-page apps took over, DOM XSS went from an edge case to a routine finding.

What Attackers Do With XSS

An alert(1) proves the bug, but it is not the point. Once an attacker can run JavaScript in your session, they inherit your access to the page. The realistic impact usually falls into a few buckets:

• Session hijacking. Reading document.cookie and sending it elsewhere hands the attacker your logged-in session, unless the session cookie is marked HttpOnly. That single flag is why cookie theft is far less trivial than tutorials from a decade ago suggest.
• Acting as the user. Even without the cookie, the script can make authenticated requests on your behalf: change your email, add an admin, transfer funds. It runs from inside your session, so the app sees legitimate actions from a legitimate user.
• Credential capture. A script can rewrite the page to add a fake login prompt or a keystroke listener on a real one, harvesting what you type into a form that looks entirely genuine.
• Defacement and phishing. Because the code controls the DOM, it can replace content, inject misleading messages, or redirect to an attacker-controlled page, all under the trusted domain in the address bar.

When testing real applications, the finding that gets a report taken seriously is rarely the alert box. It is the follow-up: proving the payload can perform an authenticated action, in a lab or an authorized scope, so the severity is undeniable. That is the difference between "reflected value" and "account takeover" in a bug report.

XSS Payloads and Examples

You do not need an exotic payload to find XSS. You need a probe that survives the context it lands in. Start by injecting a harmless marker and looking at where and how it comes back in the HTML source, then shape the payload to the context. A few standard proof-of-concept probes, the kind used every day in authorized testing:

• The classic tag: <script>alert(1)</script> works when your input lands between tags in an HTML body.
• The attribute breakout: "><svg onload=alert(1)> escapes a value that was placed inside an HTML attribute.
• The event handler: <img src=x onerror=alert(1)> runs when <script> is filtered but other tags are not.
• The JavaScript context: ';alert(1)// breaks out of a string that was written into an inline script block.

The lesson in that list is context. The same input is harmless in one place and executable in another, which is why the fix has to be context-aware too. Use alert(document.domain) rather than alert(1) when you demonstrate a finding, since it proves which origin the script is running under and reads clearly in a report.

For a real, curated reference of payloads to try against targets you are authorized to test, the community-maintained PayloadsAllTheThings XSS list is the one most testers keep bookmarked. Treat it as a study aid, not a spray list.

How to Prevent XSS

How do you prevent cross-site scripting? Encode output for the context it appears in, so untrusted data is always rendered as inert text rather than parsed as markup or script. Encoding is the primary defense, and a Content Security Policy plus a modern framework's auto-escaping turn it into defense in depth. The OWASP XSS Prevention Cheat Sheet lays out the full ruleset; here is what actually moves the needle.

• Context-aware output encoding. Escape data based on where it lands. HTML-encode for element bodies (< becomes <), attribute-encode inside attributes, and never place untrusted data directly into a script block or an event handler. This is the fix that ends the vulnerability.
• Let the framework escape by default. React, Angular, and Vue encode interpolated values automatically, which is why modern apps have less XSS than the PHP era. The trap is the escape hatch: dangerouslySetInnerHTML, Angular's bypassSecurityTrust, and any raw innerHTML assignment opt you back out of safety. Audit every one.
• Deploy a Content Security Policy. A strict CSP that blocks inline scripts and restricts sources is a strong second layer. It will not fix a bug, but it can stop a payload from executing or from calling home even when one slips through.
• Set HttpOnly on session cookies. This keeps JavaScript from reading the cookie, which neutralizes the most direct form of session theft. Pair it with Secure and a sensible SameSite value.
• Sanitize when you truly must render HTML. If users legitimately submit rich text, do not hand-roll a filter. Run it through a vetted library like DOMPurify, which is built and tested specifically to strip dangerous markup while keeping safe formatting.

Notice what is not at the top of that list: input validation. Filtering input is a useful supporting layer, and rejecting obviously malformed data is good hygiene, but it cannot be your XSS defense. The same value is dangerous in one output context and fine in another, so the reliable control lives at output, where you know the context. Validate on the way in, encode on the way out.

How to Test for XSS

How do you find XSS in an application? Inject a unique marker into every input, then read the raw HTML response to see where it appears and whether it was encoded. Where your marker comes back intact and unescaped, shape a payload for that exact context and confirm it executes. A practical routine:

1. Map every input. URL parameters, form fields, headers, cookies, and anything a single-page app reads from the URL fragment. Each is a candidate source.
2. Inject a marker, not a payload, first. Send a harmless string like xss7391 and search the response source for it. If it appears encoded, that context is defended. If it appears raw, you have a lead.
3. Match the payload to the context. Between tags, inside an attribute, or within a script block each need a different breakout. This is where understanding the three contexts pays off.
4. Automate the breadth. A scanner in Burp Suite or a tool like Dalfox will fuzz hundreds of parameters far faster than you can by hand. Point it only at systems you own or are authorized to test.

Doing this by hand a few times builds the instinct to spot an unescaped output in a code review, which is where prevention is cheapest. Learning to exploit XSS and learning to prevent it are the same skill seen from two sides, and running the attack in a controlled lab is the fastest way to make the defensive habit automatic.

Legal and Ethical Considerations

• Test only on systems you own, on intentionally vulnerable practice targets, or within the defined scope of an authorized bug bounty or engagement.
• Use a benign proof such as alert(document.domain) to demonstrate a finding. Do not deploy payloads that steal real users' cookies or data to prove impact.
• If you find XSS in someone else's application, report it through their disclosure process and stop there.
• The labs and courses linked here exist so you can practice the attack and the defense legally, on targets built for exactly that.