CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
BaseStableExploit Likelihood: High🏆 #1 in Top 25 (2024)
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
There are many variants of cross-site scripting, characterized by a variety of terms or involving different attack topologies. However, they all indicate the same fundamental weakness: improper neutralization of dangerous input between the adversary and a victim.
Technical Details
Structure
Simple
Vulnerability Mapping
ALLOWED
Applicable To
Languages
Not Language-Specific
Platforms
🏆 CWE Top 25 Historical Ranking
2023:#2
Score: 45.54
4,278 CVEs
2024:#1↑1
Score: 45.54
4,442 CVEs
Trend:Worsening (moved down 1 ranks)
Security Consequences
Scope
Access ControlConfidentiality
Impact
Bypass Protection MechanismRead Application Data
The most common attack performed with cross-site scripting involves the disclosure of private information stored in user cookies, such as session information. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity on behalf of the victim to an attacker-controlled system (such as sending all site cookies to a given E-mail address). This could be especially dangerous to the site if the victim has administrator privileges to manage that site. This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.
Scope
IntegrityConfidentialityAvailability
Impact
Execute Unauthorized Code or Commands
In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws, for example, "drive-by hacking."
Scope
ConfidentialityIntegrityAvailabilityAccess Control
Impact
Execute Unauthorized Code or CommandsBypass Protection MechanismRead Application Data
The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.
Mitigation Strategies
Phase
ImplementationArchitecture and Design
Description
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Cascading Style Sheets and style property etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.
Detection Methods
Method
Automated Static Analysis
Description
Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when multiple components are involved.
Effectiveness
Moderate
Method
Black Box
Description
Use the XSS Cheat Sheet [REF-714] or automated test-generation tools to help launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.
Effectiveness
Moderate
Code Examples & CVEs
Demonstrative Examples
The following code displays a welcome message on a web page based on the HTTP GET username parameter (covers a Reflected XSS (Type 1) scenario).
Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as
The following code displays a Stored XSS (Type 2) scenario.
The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
BadJSP
<%Statement stmt = conn.createStatement();ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);if (rs != null) {rs.next();String name = rs.getString("name");}%> Employee Name: <%= name %>
The following code displays a Stored XSS (Type 2) scenario.
The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
BadASP.NET
<%protected System.Web.UI.WebControls.Label EmployeeName;...string query = "select * from emp where id=" + eid;sda = new SqlDataAdapter(query, conn);sda.Fill(dt);string name = dt.Rows[0]["Name"];...EmployeeName.Text = name;%><p><asp:label id="EmployeeName" runat="server" /></p>
The following code consists of two separate pages in a web application, one devoted to creating user accounts and another devoted to listing active users currently logged in. It also displays a Stored XSS (Type 2) scenario.
The following code consists of two separate pages in a web application, one devoted to creating user accounts and another devoted to listing active users currently logged in. It also displays a Stored XSS (Type 2) scenario.
CreateUser.php
BadPHP
$query = 'Select * From users Where loggedIn=true';$results = mysql_query($query); if (!$results) {exit;} //Print list of users to page echo '<div id="userlist">Currently Active Users:';while ($row = mysql_fetch_assoc($results)) {echo '<div class="userNames">'.$row['fullname'].'</div>';}echo '</div>';
The following code is a simplistic message board that saves messages in HTML format and appends them to a file. When a new user arrives in the room, it makes an announcement:
An attacker may be able to perform an HTML injection (Type 2 XSS) attack by setting a cookie to a value like:
BadPHP
$name = $_COOKIE["myname"];$announceStr = "$name just logged in."; //save HTML-formatted message to file; implementation details are irrelevant for this example. saveMessage($announceStr);
The following code attempts to stop XSS attacks by removing all occurences of "script" in an input string.
Because the code only checks for the lower-case "script" string, it can be easily defeated with upper-case script tags.
BadJava
public String removeScriptTags(String input, String mask) {return input.replaceAll("script", mask);}
Additional facts reviewed against primary or authoritative security sources.
Combine code review with SAST, DAST, IAST, and fuzzing
Inventory every path that carries untrusted data into browser output, including parameters, headers, URLs, cookies, JSON, SOAP, and XML. Pair source review with automated fuzzing and dynamic tests, then run SAST, DAST, and IAST in CI/CD so server-rendered, stored, and client-side injection paths are checked before release. Treat findings as data-flow defects from source to browser interpreter, not merely suspicious string matches.
Match the XSS defense to the browser parsing context
Start with the framework's default output encoding, then encode untrusted values for their exact HTML, attribute, URL, CSS, or JavaScript context. When users must author HTML, sanitize it with a maintained sanitizer and avoid changing the content afterward. Replace unsafe DOM sinks such as innerHTML with text-only sinks where possible; treat Content Security Policy as defense in depth rather than the primary fix.
For DOM-based XSS paths, route data through narrowly scoped Trusted Type policies before it reaches injection sinks such as innerHTML, document.write, script URLs, or eval-like APIs. Enforce Content-Security-Policy: require-trusted-types-for 'script' so unsupported raw string writes fail instead of executing, and restrict allowed policy names with the trusted-types directive. Use a temporary default policy only to locate and migrate legacy sink writes.
Model user-assisted reflected XSS with CVE-2025-20250
NVD maps CVE-2025-20250 in Cisco Webex to CWE-79: insufficient filtering allowed an unauthenticated remote attacker to craft a malicious link and persuade a user to open it. The CNA scored it CVSS 3.1 6.1 Medium with user interaction required and changed scope, with low confidentiality and integrity impact. Use this scenario to test link-delivered reflections, output encoding, user-interaction assumptions, and whether injected script crosses a trust boundary in the victim's browser.
Track CWE-79 under OWASP A05:2025 Injection while keeping the control plan specific to the browser interpreter. The mapping makes XSS part of the broader injection governance program: separate untrusted data from executable syntax, cover all interpreter boundaries in review and testing, and measure remediation through the same SAST, DAST, IAST, and fuzzing pipeline used for other injection classes. Preserve CWE-79 as the precise root-cause identifier for individual findings.
Exercise every reflected input in its actual browser context
Follow WSTG-INPV-01 by enumerating visible and hidden input vectors, sending harmless markers and context-aware test strings, and locating each reflection in returned HTML. Verify whether HTML, attribute, URL, CSS, and JavaScript contexts receive the correct output encoding. Repeat with alternate encodings and syntax variations, and assess actual browser execution rather than assuming a denylist, browser feature, or web application firewall blocks the payload.
What is CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')?+
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. There are many variants of cross-site scripting, characterized by a variety of terms or involving different attack topologies. However, they all indicate the same fundamental weakness: improper neutralization of dangerous input between the adversary and a victim.
Is CWE-79 in the CWE Top 25 Most Dangerous Software Weaknesses?+
Yes. CWE-79 ranked #1 in the CWE Top 25 for 2024, associated with 4,442 CVEs that year. The CWE Top 25 highlights the most common and impactful software weaknesses based on real-world vulnerability data.
What are the security consequences of Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')?+
If exploited, CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) it can compromise Access Control, Confidentiality, Integrity and Availability, leading to outcomes such as Bypass Protection Mechanism, Read Application Data and Execute Unauthorized Code or Commands.
How do you prevent or mitigate Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')?+
Recommended mitigations for CWE-79 include: Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Cascading Style Sheets and style property etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.
How is Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') detected?+
CWE-79 can be detected using Automated Static Analysis and Black Box. Combining automated tooling with manual review typically yields the best coverage.
Which programming languages are affected by Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')?+
CWE-79 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
What are real-world examples of Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')?+
MITRE documents real CVEs mapped to CWE-79, including CVE-2024-49038, CVE-2024-54142, CVE-2021-25926, CVE-2021-25963 and CVE-2021-1879. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
What is the difference between a CWE and a CVE?+
A CWE (Common Weakness Enumeration) like CWE-79 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.