Cross-site scripting (XSS) — SY0-701
Master XSS for Security+ SY0-701: definition, reflected vs. stored variants, the client-side execution trap, and exam recognition signals.
WHAT IT IS
Cross-site scripting (XSS) is a type of injection attack in which malicious scripts are injected into otherwise benign and trusted websites. The vulnerability exists when a web application includes unvalidated, unsanitized user input in dynamically generated output sent to other users' browsers. Because the browser receives the script as part of a response from a trusted site, it executes it with the permissions of that site's origin — enabling the attacker to access cookies, session tokens, or other sensitive information the browser retains for that site.
NIST (SP 800-63-4) defines XSS as "a vulnerability that allows attackers to inject malicious code into an otherwise benign website," noting that websites become vulnerable when they display user-supplied data without sanitizing it to prevent executable code.
Mental model
Think of XSS as a ventriloquist attack on the browser. The attacker does not speak directly to the victim — the attacker puts words in the trusted website's mouth. The browser hears those words coming from a source it trusts and obeys them.
The key boundary being violated is the browser's same-origin trust: the browser cannot distinguish between a script the site intentionally served and a script an attacker slipped into the site's response.
When to use it
XSS is frequently confused with SQL injection because both involve injecting malicious content through user input. The distinction is where the injected payload executes and what it targets.
| XSS | SQL Injection | |
|---|---|---|
| Where payload executes | Victim's browser (client side) | Database server (server side) |
| What is targeted | Other users' sessions and browser state | Backend database queries and data |
| Injected content type | Script/HTML markup | SQL query syntax |
| Primary victim | End users of the application | The application's data store |
| Core failure | Output not encoded before display | Input not parameterized before query construction |
Use "XSS" when the scenario involves a script running in another user's browser context. Use "SQL injection" when the scenario involves manipulating a database query.
COMMON MISCONCEPTION
The trap: XSS targets the server.
Because XSS involves a web application and the injected content often passes through a server, candidates sometimes classify it as a server-side attack or conflate it with attacks that directly compromise server data.
XSS targets the client — specifically, other users' browsers. The server is the unwitting delivery mechanism, not the victim. OWASP's description makes this explicit: "the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser" — all client-side assets, not server-side ones.
A second misconception is that XSS requires the attacker to already have access to the vulnerable site. In reflected XSS, the attacker only needs to trick a victim into clicking a crafted link; no persistent access to the server is required.
How it shows up on the exam
The Security+ objective for this domain (Threats, Vulnerabilities, and Mitigations) asks candidates to distinguish attack types by mechanism and target, not just by name. For XSS, the cognitive target is recognizing where execution happens and who is harmed.
Scenario-based questions may describe:
- A comment field or forum post that causes other users' browsers to run unexpected code — this points toward stored (persistent) XSS, where OWASP notes the injected script is "permanently stored on the target servers, such as in a database, message forum, or comment field."
- A crafted URL or link that, when clicked, causes a user's browser to execute a script reflected back in an error message or search result — this points toward reflected (non-persistent) XSS.
Signal phrases to recognize: "other users are affected," "session cookie stolen," "browser executes script," "user input displayed without encoding," "malicious link sent to victim."
Candidates often confuse this with a server compromise scenario. If the question describes data being exfiltrated from a database or administrative server access being gained, SQL injection or a different attack class is more likely the answer than XSS.
Attack flow
Related concepts
- Memory Vulnerabilities — another class of vulnerability exploiting improper handling of untrusted input, but at the memory/buffer level rather than the browser rendering layer.
- Race Conditions — a timing-based vulnerability class; contrasts with XSS, which exploits trust boundaries rather than execution timing.
- SQL Injection — the closest neighbor to XSS; both are injection attacks, but SQL injection targets server-side database queries while XSS targets client-side browser execution.
Sources
Every claim on this page traces to the public exam blueprint and official documentation: