What Is XSS (Cross-Site Scripting)? Definition & Examples

By NHI Mgmt Group Updated November 3, 2026 Domain: Threats, Abuse & Incident Response

Cross-site scripting is a web vulnerability where an attacker injects script that runs in a victim’s browser in the context of a trusted site. It usually happens when user-controlled input is reflected, stored, or inserted into the page without proper output encoding or content sanitisation.

What XSS Means in Practice

Cross-site scripting is not just “bad input handling”; it is a browser trust failure. An attacker’s script runs inside the victim’s session for a trusted application, which means the malicious code can act with the page’s own permissions, access visible data, and interact with the page as if it were legitimate content.

That is why XSS matters even when the injected code is small. The browser executes it in a security context the user and application both expect to be safe, so the attack can blur the boundary between trusted application logic and untrusted data.

How XSS Becomes Exploitable

XSS usually appears when untrusted data is placed into HTML, JavaScript, an attribute, or a URL context without the right output encoding or sanitisation. The core mistake is not simply “accepting user input”, but failing to preserve the boundary between data and executable code at the point where the application renders content.

Different XSS forms reflect different trust failures. Reflected XSS returns malicious input immediately, stored XSS persists it for later delivery, and DOM-based XSS emerges when client-side code writes unsafe data into the DOM. In all three cases, the browser becomes the execution environment for attacker-controlled script.

The risk increases when the vulnerable page is high-trust, widely visited, or part of a workflow that handles authentication, payments, support tickets, messaging, or administrative actions. A small injection point in one feature can become a full application compromise path if the script can read data, send requests, or modify page behaviour.

What XSS Can Let an Attacker Do

XSS can expose information that the victim can see in the browser, including personal data, form contents, or page-generated secrets embedded in the DOM. It can also perform actions as the victim, because the malicious script runs inside the same origin as the trusted site.

That means the impact is often broader than visible pop-ups or defacement. Attackers may steal session information available to script, trigger unwanted transactions, capture keystrokes, or pivot into account abuse through in-browser actions that look legitimate to the application.

Because the payload executes in a trusted origin, XSS can also undermine user confidence in the site itself. It is an integrity issue first, but it often becomes a confidentiality and account-abuse problem as soon as the injected code can observe, transform, or relay sensitive page content.

How Defenders Reduce XSS Exposure

The most reliable defence is context-aware output encoding, applied where data is rendered, not where it is collected. Input validation still matters, but it should support safe handling rather than be treated as the only barrier.

When HTML must be accepted, sanitisation should remove executable constructs rather than merely strip a few obvious tags. Modern hardening patterns such as Content Security Policy and Trusted Types add useful defence in depth, especially against DOM-based injection paths and unexpected script creation.

Defenders should also test the actual output contexts used by the application, because the right control for text nodes is not the same as the control for attributes, URLs, or script blocks. Cross-Site Scripting (XSS) Prevention Guide is a practical reference for those context-specific defences, including stored, reflected and DOM XSS.

For a broader view of where XSS sits alongside other web attack classes, Web Application Attacks Guide helps place it in the wider pattern of injection and browser-side abuse. For teams aligning their prevention work with common injection controls, OWASP Top 10 A05 Guide is useful because it treats XSS as part of the broader injection problem space.

How XSS Affects Browser and Session Security

XSS is dangerous because it abuses the browser’s role as a trusted client for the application. The attacker does not need to break the server to gain leverage, because the victim’s browser becomes the delivery vehicle and execution runtime.

That is also why browser-side protections matter. A strong content model, safe DOM handling, and a restrictive execution policy can prevent many payloads from becoming executable even when a flawed render path still exists. In practice, XSS defence is as much about preserving browser trust boundaries as it is about filtering input.

One subtle point is that XSS often exposes weaknesses in surrounding design decisions. If a page relies on inline scripts, unsafe templating, or client-side insertion of untrusted values, the application creates more opportunities for a payload to become code. Security teams should treat those patterns as structural risk, not isolated bugs.

Useful companion guidance for developers is the XS-Leaks Guide, which explains adjacent browser-side information disclosure paths, and the CSRF Prevention Guide, which helps separate XSS from request-forgery controls that are related but not interchangeable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V1 — Encoding and Sanitization	XSS is prevented by context-aware output encoding and sanitization.
	V3 — Web Frontend Security	XSS commonly exploits unsafe browser-side rendering and DOM handling.
	V16 — Security Logging and Error Handling	XSS testing and incident review depend on reliable logging of suspicious input and script execution.
Recommendation — Apply V1 to encode untrusted data for the exact output context before rendering it. Use V3 to harden client-side rendering paths and prevent unsafe DOM insertion. Use V16 to retain logs that support XSS detection, investigation, and post-incident review.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	XSS often begins with unsafe handling of attacker-controlled input.
	SI-11 — Error Handling	Error pages and exception paths can become XSS injection points if they reflect unsafe data.
	AU-6 — Audit Review, Analysis, and Reporting	XSS investigations require review of suspicious page activity and related access events.
Recommendation — Apply SI-10 to validate input before it reaches rendering or processing logic. Use SI-11 to prevent error handling from reflecting untrusted content into responses. Use AU-6 to review logs for signs of script injection and abnormal browser-side actions.
CIS Controls v8	CIS-16 — Application Software Security	XSS is a core application security weakness addressed by secure coding and testing.
	CIS-13 — Data Protection	XSS can expose sensitive data rendered in the browser.
Recommendation — Use CIS-16 to build and test applications for XSS resistance before release. Use CIS-13 to reduce exposure of sensitive data that XSS could reveal in the client.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org

XSS (Cross-Site Scripting)