CWE-79 is a weakness class for cross-site scripting. It occurs when an application includes untrusted input in a web page without proper output encoding or sanitisation, allowing attacker-controlled script to run in a user's browser. The main controls are context-aware encoding, sanitisation, and input handling.
What CWE-79 Means in Practice
CWE-79 describes a web application weakness where untrusted input is rendered into a page without the right context-aware encoding or sanitisation. The result is cross-site scripting, where attacker-controlled script runs in a victim’s browser and can manipulate content, steal data, or act within the user’s session.
That makes the weakness less about a single bug and more about a broken trust boundary between application input and browser execution. Because browsers interpret script in context, the same unsafe data flow can become dangerous in HTML, attributes, JavaScript, CSS, or URL contexts if the output handling is wrong.
Why Cross-Site Scripting Is Dangerous
XSS is dangerous because the browser treats injected content as part of the trusted page. An attacker can use that execution path to read page data, alter what the user sees, capture tokens or form inputs, trigger actions on the user’s behalf, or stage follow-on attacks such as phishing or account abuse.
The impact depends on where the script lands and what the page can reach. Stored XSS tends to have the broadest blast radius because the malicious payload is persisted and replayed to many users, while reflected and DOM-based variants often depend on a crafted request or client-side flow. For broader prevention patterns, see the Cross-Site Scripting (XSS) Prevention Guide.
How Teams Identify and Reduce Exposure
Exposure usually comes from places where applications render user input, template data, rich text, error messages, search results, comments, profile fields, or client-side state into HTML. Teams should inventory those sinks, confirm where the application builds output, and review whether each context uses the right escaping rules instead of generic filtering.
Practical review also includes testing for reflected, stored, and DOM-based paths, because the vulnerable location may sit in server-side rendering, API-driven front ends, or browser-side code that writes into the DOM. The classic weakness taxonomy and its place in the broader CWE landscape are usefully summarised in the CWE Top 25 Guide.
Defensive Controls That Actually Matter
The main control is context-aware output encoding, not a one-size-fits-all sanitizer. HTML element content, attribute values, JavaScript strings, CSS, and URLs each need different handling, and sanitisation only helps when the application intentionally allows a subset of safe markup.
Good practice also includes reducing reliance on inline script, using browser-side protections such as Content Security Policy where appropriate, and making sure validation happens before data reaches a rendering sink. The broader injection-control family is captured well in the OWASP Top 10 A05 Guide, which places XSS alongside related injection failures and their defences.
Risk and Threat Considerations
XSS remains a material risk because it turns a trusted application into a delivery mechanism for attacker code. The most serious outcomes usually involve session abuse, fraud, data theft, or trust erosion when users can no longer rely on what the application displays.
Failure mechanism: The application inserts attacker-controlled input into a browser-executed context without the encoding or sanitisation that matches that exact context, so the browser interprets the payload as script rather than data.
Impact: An attacker may steal session data, alter page content, perform actions as the victim, or pivot into broader compromise of user accounts and business workflows.
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 | CWE-79 is prevented by context-aware encoding and sanitization in web output handling |
| V3 — Web Frontend Security | DOM-based XSS often arises in browser-side rendering and unsafe DOM writes | |
| V16 — Security Logging and Error Handling | XSS payload testing and detection benefit from logging and safe error handling in web apps | |
| Recommendation — Apply V1 controls to encode untrusted data for each output context before rendering it. Review front-end DOM interactions and block unsafe script-inserting patterns. Log suspicious input and rendering failures without exposing executable content. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | XSS is a failure to validate and neutralize untrusted input before use in output |
| SC-18 — Mobile Code | XSS causes untrusted code to execute in a browser context, similar to unsafe mobile code execution | |
| Recommendation — Implement SI-10 to validate, encode, and sanitize inputs before they reach rendering sinks. Restrict and inspect executable content that can reach user-facing rendering paths. | ||
| CIS Controls v8 | 16 — Application Software Security | XSS is a core application software weakness addressed through secure coding and testing |
| Recommendation — Use Control 16 to test application output handling and remediate XSS-prone code paths. | ||
Practitioner Guidance
Why practitioners should care: CWE-79 is not just a code-quality issue, it is an abuse path that can convert ordinary input handling mistakes into browser execution. Teams should treat it as a recurring design and review concern, especially anywhere content is assembled from multiple sources or rendered dynamically.
What to watch for: Pay close attention to places where developers “sanitize” once and reuse the result everywhere, or where front-end code writes raw strings into the DOM. Those patterns often fail because the correct defence depends on the sink context, not just the source.
Related resources from NHI Mgmt Group
- What do teams get wrong when they rely on top CWE rankings alone?
- Why do repeat CWE classes keep causing breaches even when teams know about them?
- How should security teams use the CWE Top 25 and OWASP Top 10 together without duplicating work?
- Why do CWE-level findings provide stronger audit evidence than OWASP category labels?
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.
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