A classic XSS demonstration uses a shopping cart application with a credit card number field that performs no input checking. Normally, the field accepts a card number and processes the purchase. Because there is no validation, the attacker can enter JavaScript in the credit card field instead of a number.
In a simplified demo, the attacker enters a script that creates an alert displaying the user's session ID. When the purchase button is clicked, the script executes and a pop-up appears showing the session information from the cookie.
In a real attack, the script would not create a visible alert — it would silently read document.cookie and send the session token to the attacker's server via a fetch request or an image load in the background. The victim sees a normal purchase confirmation page. The attacker receives their session token.
What this demonstrates: Any input field that renders user content in the browser without encoding can be an XSS entry point — not just search boxes. Credit card fields, name fields, address fields, and URL parameters are all potential vectors if the application fails to encode output.
Security researcher Aaron Guzman examined the Subaru web portal for vehicle management in June 2017. His findings combined multiple vulnerabilities into a serious breach chain:
Vulnerability 1 — Never-expiring token: When a user authenticated to the Subaru portal, they received a bearer token. Unlike well-designed systems where tokens expire after 24 hours or a session ends, this token never expired. Anyone who obtained a copy of the token could use it indefinitely.
Vulnerability 2 — Overpowered token: The token allowed any service request — including adding an email address to another user's account. Once your email was associated with another account, the token granted full access to that person's vehicle management: remote start, door unlock, GPS tracking, and account modification.
Vulnerability 3 — XSS delivery mechanism: The Subaru web front-end contained an XSS vulnerability. An attacker could craft a malicious link exploiting this flaw. If a Subaru owner clicked the link, the XSS payload executed in their browser, captured their authentication token, and sent it to the attacker.
Combined impact: Click link → token stolen → token never expires → attacker adds their email to victim's account → permanent, full control of victim's vehicle. The XSS was the theft mechanism; the token design was the amplifier. Guzman responsibly disclosed the vulnerabilities, and Subaru remediated them.
The most damaging form of stored XSS occurs when the injected script is designed to self-propagate across a social network. Here is how a propagating stored XSS attack unfolds:
Step 1: An attacker posts a message on a social network that appears normal but contains hidden JavaScript. The script is stored in the platform's database alongside the post content.
Step 2: Any user who views the post has the script execute in their browser. The script reads their session cookie and sends it to the attacker. It also — automatically and silently — re-posts the same message (including the script) to their own profile.
Step 3: Every friend or follower who sees the re-posted message triggers the same sequence. Each viewer becomes a vector. The message spreads exponentially — one post can reach thousands of accounts within hours.
Historical examples of social network XSS worms have affected platforms with hundreds of thousands of users within a single day. The Samy worm (MySpace, 2005) remains one of the most famous examples — it added over one million friends to the creator's profile in under 24 hours through self-propagating stored XSS.
Scenario: An attacker sends a targeted email to a company's CFO containing a link that appears to go to the company's legitimate financial portal. When the CFO clicks the link, a script executes in their browser and their session cookie is transmitted to an external server. The script is not present on the portal's database and only executes as a result of the specific link being clicked. Which type of XSS is this?
Answer: Reflected (non-persistent) XSS. The script is embedded in the link/URL, is not stored on the server, and only executes when the specific crafted link is clicked. The attack targeted a specific individual (the CFO) via a crafted link delivered by email. The server reflected the script in its response without storing it. These are the defining characteristics of reflected XSS.
Scenario: A security team investigates a series of user account compromises on their customer support forum. Affected users all visited the same forum thread but received no suspicious emails or messages. The team finds that a post in the thread contains embedded JavaScript. Which attack type is this, and which users are at risk?
Answer: Stored (persistent) XSS. The malicious script was posted to the forum and saved in the database. Every user who viewed the thread had the script execute automatically — no crafted link required. All users who visited the thread are at risk. The defining characteristics: script is stored server-side, delivery requires no attacker-user interaction, all page viewers are affected.
Scenario: A web application allows users to post comments that are displayed on a public forum. The security team identifies that an attacker could inject JavaScript via comment fields. The development team proposes three options: (A) add a WAF, (B) apply output encoding to all user-generated content before rendering, (C) require user authentication before viewing comments. Which is the BEST primary defense?
Answer: B — output encoding. Output encoding addresses the root cause: it ensures user-supplied content is rendered as visible text rather than executed as script, regardless of what the content contains. A WAF (A) can detect some XSS patterns but can be bypassed through encoding variations and obfuscation. Requiring authentication (C) limits who can view content but does not prevent XSS execution for authenticated users — and many public forums deliberately allow unauthenticated viewing. Output encoding prevents the injection from having any effect whether or not other controls are in place.
Scenario: Two vulnerabilities are found in the same web application. Vulnerability A: injected input is executed by the database server. Vulnerability B: injected input is executed by the victim's browser. Which vulnerability is SQL injection and which is XSS?
Answer: Vulnerability A is SQL injection — the injected code targets the database engine, which executes it as SQL. Vulnerability B is XSS — the injected code targets the client browser, which executes it as JavaScript. Both are code injection attacks, but they target different execution environments: SQL injection exploits the server-side database; XSS exploits the client-side browser. The fix for each reflects this difference: parameterized queries for SQL injection (prevent DB execution), output encoding for XSS (prevent browser execution).