Cybersecurity glossary
What is Cross-Site Scripting (XSS)?
Learn what Cross-Site Scripting (XSS) is, how reflected, stored, and DOM-based XSS differ, what attackers can do with injected scripts, and how encoding, sanitization, and CSP reduce risk.
Definition
Cross-Site Scripting (XSS) is a web security vulnerability in which untrusted data is interpreted as active content—usually JavaScript—in a victim’s browser, allowing attackers to run code in the security context of a trusted site.
Why XSS matters
Browsers treat each website origin as a trust boundary. Script from https://bank.example can touch that site’s DOM, storage, and cookie-authenticated requests. Cross-Site Scripting (XSS) lets an attacker smuggle their script into that boundary so the browser believes the trusted site asked it to run.
XSS remains foundational in web risk rankings because applications constantly combine templates, user content, redirects, and client-side rendering. One unsafe sink can convert ordinary input into account takeover.
This glossary entry defines the concept broadly. For exploitation-focused detail, see the dedicated XSS vulnerability page.
How XSS works
At root, untrusted data reaches a browser interpretation context without proper neutralization.
Attacker supplies data
Input arrives via URL parameters, forms, headers, chat messages, files, or API fields.
Application retains or reflects it
Data is echoed immediately, stored for later, or processed only in client-side script.
Unsafe sink renders it as code
HTML markup, JavaScript evaluation, or risky DOM APIs interpret the data as active content.
Victim’s browser executes it
The script runs with the origin’s privileges in the victim session.
Attacker achieves an objective
Session abuse, data theft, malware delivery, or persistent defacement follow.
XSS types compared
| Type | Where it appears | Typical delivery |
|---|---|---|
| Reflected | Request data echoed into the immediate response | Malicious link or crafted request the victim opens |
| Stored | Payload saved on the server and shown to users later | Victim simply visits a normal infected page |
| DOM-based | Client-side JavaScript writes untrusted data into unsafe sinks | URL fragment or client-only state manipulated by attacker |
Impact
Session and account abuse
Perform actions as the user or steal tokens when cookie flags and storage design allow.
In-origin phishing
Fake login forms on a real domain defeat casual URL checking.
Data exfiltration
Read page content, CSRF tokens, or API responses visible to the user.
Malware and lateral movement
Pivot from one XSS bug into admin sessions, browser exploits, or internal apps.
Prevention principles
Context-aware output encoding is the primary control. HTML body, HTML attributes, JavaScript strings, CSS, and URLs each need different encoding rules. When rich HTML is required, sanitize with a vetted library on a strict allowlist. Prefer frameworks that auto-escape by default and avoid innerHTML, document.write, and similar sinks with untrusted data.
- Encode untrusted data for the exact output context; do not apply one filter everywhere.
- Sanitize HTML with maintained libraries when markup must be allowed.
- Use HttpOnly, Secure, and appropriate SameSite cookie attributes to reduce token theft usefulness.
- Deploy a strict Content Security Policy with nonces or hashes where feasible.
- Avoid eval, new Function, and unsafe URL sinks such as location assignments with untrusted input.
- Review client-side templates and mobile webviews with the same rigor as server templates.
- Treat file uploads, markdown, SVG, and PDF previews as active-content risks.
- Test reflected, stored, and DOM paths—including authenticated areas and admin consoles.
Defense in depth
Encoding prevents bugs from becoming XSS. CSP reduces impact when something slips through. Cookie hardening limits easy session theft. WAF signatures can add noise reduction but must not be mistaken for a root-cause fix.
The practical takeaway
Cross-Site Scripting (XSS) injects attacker-controlled active content into a trusted web origin. Reflected, stored, and DOM-based variants differ in delivery, not in the core danger: attacker code running as the site.
Prevent XSS by making unsafe interpretation impossible—encode, sanitize, use safe defaults, and add CSP. If user data can become browser code, assume attackers will try to make that happen.
Related security terms
Reflected XSS
XSS where the payload is echoed immediately from a request into the response.
Stored XSS
XSS where the payload is persisted and later delivered to other users.
DOM-Based XSS
XSS that arises from unsafe client-side JavaScript DOM sinks.
Content Security Policy (CSP)
A browser policy layer that can reduce XSS impact when strictly configured.
Cross-Site Scripting (XSS)
In-depth vulnerability guide covering exploitation mechanics and remediation.
Frequently asked questions
What is XSS in simple terms?
XSS happens when a website accidentally treats attacker-controlled text as code. The victim’s browser then runs that code as if it came from the trusted site.
What can attackers do with XSS?
They can steal session tokens if cookies allow it, perform actions as the user, rewrite pages for phishing, capture keystrokes, and pivot into further account compromise.
What are the main XSS types?
Reflected XSS comes back in an immediate response. Stored XSS is saved and shown later. DOM-based XSS happens when client-side script unsafely handles data in the browser.
Does HTTPS prevent XSS?
No. HTTPS protects transport. XSS exploits how the application handles and renders data inside an already trusted page.
Is XSS only a JavaScript problem?
JavaScript is the most common payload language in browsers, but XSS is fundamentally about injecting active content into a trusted origin’s page—including some HTML and URL contexts.
How do you prevent XSS?
Encode output for the correct context, sanitize HTML when rich content is required, use safe framework defaults, avoid dangerous sinks, and add a strong Content Security Policy.
Can a WAF stop XSS?
A WAF may block known payloads, but encoding and safe rendering are the real fixes. Attackers routinely obfuscate input to bypass filters.
References
Explore authoritative guidance and frameworks related to cross-site scripting (xss).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.