Cross-Site Scripting (XSS) Explained: Types & Defenses

Cross-Site Scripting (XSS)

Oct 9, 2026 · @Ken

Cross-site scripting lets an attacker run their own code inside a page the victim already trusts, and for the Security+ exam, the key idea to hold onto is that the malicious script executes with all the trust and access the legitimate site already has — the browser has no way to tell the attacker's code apart from the site's own.

How XSS Attacks Work

XSS is a client-side attack: the malicious code doesn't run on the web server, it runs inside the victim's own browser, in the security context of whatever site the victim is currently looking at. That distinction matters because browsers enforce something called the same-origin policy — a page from one site normally can't read cookies, session tokens, or page content that belongs to a different site. XSS doesn't break that rule; it exploits it. If an attacker can get their script to execute as if it came from the trusted site, the same-origin policy now protects the attacker's code too.

JavaScript is the payload language almost every XSS attack uses, simply because every modern browser runs it by default and it has full access to the page's content, cookies, and the actions a logged-in user is able to take. The root cause is almost always the same: a site takes input from a user — a search box, a comment field, a URL parameter — and displays that input back on the page without properly checking or neutralizing it first. If that input happens to be a <script> tag instead of ordinary text, and the site renders it without sanitizing it, the browser has no way to know that script wasn't supposed to be there.

The Three Types of XSS

Reflected XSS is the least persistent version. The malicious script rides along in the request itself — often buried in a URL parameter — and the server immediately reflects it back in the response without storing it anywhere. Because it isn't stored, the attacker has to get the victim to click a specific crafted link, usually through a phishing email or text, for the attack to fire at all.

Stored XSS is more dangerous precisely because it doesn't need a crafted link. The attacker submits the malicious script once — through a comment field, a forum post, a user profile — and the server saves it. From that point on, every visitor who loads that page executes the script automatically, with no phishing step required.

DOM-based XSS is the odd one out: the server's response never changes at all. Instead, client-side JavaScript already running on the page takes attacker-controlled data — often straight out of the URL — and unsafely inserts it into the page's Document Object Model. The vulnerable code is entirely in the browser, which is why this variant can slip past server-side filters that only ever look at what the server sends out.

Delivery Tricks: Iframes, .js URLs, and Percent Encoding

Attackers rarely paste a raw, obvious <script> tag into a form and hope nobody notices. A malicious HTML iframe can silently embed attacker-controlled content inside what looks like a normal page, loading a hidden frame that runs its own script without the visible page ever appearing to change. A link or injected tag pointing to an external URL ending in .js is just as effective — it tells the browser to fetch and execute a full JavaScript file from a server the attacker controls, rather than cramming the whole payload inline.

Where things get sneakier is percent encoding. A lot of input filters are written to block the literal characters < and >, since those are what open and close an HTML tag. Percent-encode those same characters as %3C and %3E, though, and a filter that's only checking for literal angle brackets can let the payload sail straight through — the browser still decodes and renders it as a real tag once it reaches the page. This is exactly why XSS defenses that only look for an exact string match on dangerous characters tend to fail; decoding has to happen before input is validated, not after.

What an Attacker Can Do Once a Script Runs

Because the injected script executes with the same access as the legitimate page, it can read and exfiltrate session cookies, which is often the fastest path into full session hijacking — the attacker replays the stolen token and is logged in as the victim without ever knowing their password. It can also silently submit forms, log keystrokes, or redirect the victim to a convincing fake login page. None of this requires compromising the server itself — the browser just executed code it had no way to recognize as hostile.

Defending Against XSS

The core fix is treating user input as data, never as code. Input validation and sanitization checks and cleans what a user submits before it's ever stored or displayed, ideally decoding anything percent-encoded first so an encoded payload can't slip past the check. Output encoding goes a step further at render time, converting characters like < and > into their harmless display equivalents so the browser renders them as text instead of executing them as markup. A Content Security Policy adds a browser-level safety net, letting a site declare which sources scripts are allowed to load from, so even a successfully injected tag pointing at an attacker's server can be blocked from running. Marking session cookies HttpOnly keeps client-side JavaScript from reading them at all, which blunts the payoff of an attack even when the injection itself isn't caught. A WAF adds another layer in front of the application, inspecting incoming requests for known attack patterns before they reach the vulnerable code.

XSS vs. Its Web-Based Neighbors

CompTIA groups XSS with SQL injection under the same "web-based" vulnerability category, and it's worth being clear on why they differ: SQL injection manipulates the database query a site builds from user input, while XSS manipulates what runs in the victim's browser. A related but distinct attack is CSRF, which tricks an already-authenticated browser into submitting a request the victim never intended — no script injection required, just abuse of an active session. The application vulnerabilities CompTIA lists alongside the web-based category — buffer overflow and race conditions — target an application's own memory and timing instead. Same broad objective, several genuinely different mechanisms.

Exam Tips: Where This Fits in SY0-701

XSS sits under objective 2.3, "Explain various types of vulnerabilities," part of Domain 2.0, Threats, Vulnerabilities, and Mitigations — 22% of the exam, the largest domain. The objective lists "web-based" vulnerabilities as their own named category, with SQL injection and cross-site scripting called out as the two specific examples. CompTIA's objective text doesn't break XSS down into reflected, stored, and DOM-based by name, so expect scenario questions that describe the behavior — a link that only works once versus a payload that fires for every visitor — rather than questions that simply ask you to define each term.

A few things worth locking in before test day:

• XSS is a client-side attack. The malicious code runs in the victim's browser, not on the target's server — don't confuse it with server-side attacks like SQL injection just because both fall under "web-based."
• Know the type by the delivery. A one-time crafted link is reflected; content planted for every future visitor is stored; a vulnerability in client-side JavaScript handling the DOM is DOM-based.
• Output encoding and CSP are the two strongest technical defenses. Input validation alone is easy to bypass with tricks like percent encoding if decoding doesn't happen before the check.

Quick Reference

Type	Where the payload lives	Requires a crafted link?
Reflected	Sent in the request, echoed straight back by the server	Yes
Stored	Saved on the server, served to every future visitor	No
DOM-based	Entirely in client-side JavaScript manipulating the page	Often, via a URL fragment

You don't need to memorize a taxonomy of every encoding trick. Know that XSS runs malicious script in the victim's browser under the trusted site's own permissions, know the three types by how the payload gets delivered, and know that output encoding and a Content Security Policy are what actually stop it.

Source

CompTIA Security+ SY0-701 Exam Objectives — Objective 2.3 (Domain 2.0, Threats, Vulnerabilities, and Mitigations)