The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.
View on MITREError pages may include customized 403 Forbidden or 404 Not Found pages. When an attacker can trigger an error that contains script syntax within the attacker's input, then cross-site scripting attacks may be possible.
Do not write user-controlled input to error pages.
Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
No detection method information available for this CWE.
No relationship information available for this CWE.
CWE-81: Improper Neutralization of Script in an Error Message Web Page is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page. Error pages may include customized 403 Forbidden or 404 Not Found pages. When an attacker can trigger an error that contains script syntax within the attacker's input, then cross-site scripting attacks may be possible.
If exploited, CWE-81 (Improper Neutralization of Script in an Error Message Web Page) it can compromise Confidentiality, Integrity and Availability, leading to outcomes such as Read Application Data and Execute Unauthorized Code or Commands.
Recommended mitigations for CWE-81 include: Do not write user-controlled input to error pages. Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
CWE-81 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-81, including CVE-2002-0840, CVE-2002-1053 and CVE-2002-1700. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-81 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.