XSS attack types are the main ways malicious script is injected into a web application and run in a user’s browser. They include stored, reflected, and DOM-based XSS, each exploiting different input, response, or client-side handling paths to steal sessions, alter content, or impersonate users.
What XSS attack types are
Cross-site scripting attack types are distinguished by where the malicious script is introduced and how it reaches the browser. Stored XSS lives in a backend data store, reflected XSS returns in the immediate response, and DOM-based XSS is executed through client-side code paths.
The practical distinction matters because each type has a different trust boundary. A stored payload can persist and affect many users, a reflected payload usually depends on a crafted link or request, and DOM-based XSS can bypass server-side filtering if the browser-side logic writes unsafe content into the page.
How stored, reflected, and DOM-based XSS differ
Stored XSS is the most persistent form. An attacker places script into content that the application saves, then every visitor who loads that content may execute it. This is common in comments, profiles, ticketing systems, and other user-generated content workflows.
Reflected XSS is immediate and opportunistic. The payload is embedded in a request and then reflected into the response without safe encoding. It often appears in search fields, error messages, redirect parameters, or other values the application echoes back.
DOM-based XSS is driven by client-side JavaScript rather than the server response alone. If page scripts read from the Cross-Site Scripting (XSS) Prevention Guide unsafe sources such as the URL, fragment, or browser storage and then write them into the DOM without proper handling, the browser can become the execution point.
Why XSS is dangerous
XSS matters because it runs attacker-controlled script in a trusted origin. That can let the attacker read page content, trigger actions as the victim, steal session-bearing data exposed to the browser, or alter what the user sees without needing server credentials.
Modern XSS also undermines application trust in subtle ways. It can change approval screens, insert fake prompts, redirect users, or silently harvest form input, which makes detection harder than obvious defacement.
Prevention patterns for XSS attack types
Defence depends on context, not on a single universal filter. The safest baseline is context-specific output encoding, with additional sanitisation only where untrusted HTML is intentionally allowed. Client-side code should avoid unsafe DOM sinks, and protections such as Content Security Policy and Trusted Types can reduce exploitability when they are correctly deployed.
The strongest way to think about prevention is to align handling with the data flow: encode for HTML, attributes, JavaScript, and URLs according to where the value is rendered, and treat browser-side writes as security-sensitive operations rather than UI convenience. For broader guidance on the control choices behind that approach, see the XSS Prevention Guide.
Risk and Threat Considerations
XSS is dangerous because it abuses the browser’s trust in the application origin, so even a seemingly minor injection point can become a session theft, content manipulation, or user-impersonation path. Stored XSS is especially high impact because it can scale across many victims, while DOM-based XSS is often missed when teams focus only on server-side validation.
Failure mechanism: Unsafe input reaches a rendering path, the application fails to encode or sanitise it for the final context, and the browser executes attacker-supplied script within the trusted page origin.
Impact: Attackers can hijack sessions, capture sensitive page data, perform actions as the user, alter business content, or establish durable access through injected front-end logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | XSS is fundamentally an output-encoding and sanitization problem. |
| V13 — Configuration | CSP and related browser-hardening controls affect XSS exploitability. | |
| V16 — Security Logging and Error Handling | XSS often appears through unsafe error pages and reflected messages. | |
| Recommendation — Apply V1 to encode untrusted data for the correct output context. Use V13 to harden browser-facing settings such as CSP and Trusted Types. Use V16 to log suspicious input patterns and avoid reflecting raw errors. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | XSS exploit paths begin when applications fail to constrain untrusted input. |
| Recommendation — Apply SI-10 to validate input before it reaches rendering or script-handling paths. | ||
Practitioner Guidance
What to watch for: Treat any feature that reflects, stores, or client-side renders untrusted input as a candidate XSS sink, especially when the application allows rich text, URL parameters, or dynamic DOM updates. Review both server responses and browser-side JavaScript, because DOM-based issues often survive server-side filtering.
Governance implication: XSS prevention should be owned as an application security requirement, not left to ad hoc developer judgement. Teams should standardise safe output handling, review templates and front-end code for unsafe sinks, and validate that browser protections are present where the application design depends on them.
Related resources from NHI Mgmt Group
- What are the signs that path traversal and reflected XSS are being used together in an attack chain?
- Why do trojan malware campaigns that steal usernames, passwords, and wallet data remain effective across many attack types?
- What breaks when IAM teams cannot keep up with identity-related attack types?
- Injection Attack Types