Type: Security Hotspot Detection
Default Quality Profiles:Sonar way
Analysis Level:Syntactic Analysis
Analysis Scope:Main Sources
CWE:CWE-79, CWE-80, CWE-81, CWE-82, CWE-83, CWE-84, CWE-85, CWE-86, CWE-87
SANS Top 25:Insecure Interaction Between Components
Disabling or bypassing HTML output escaping is security-sensitive. It has led in the past to the following vulnerabilities:
To mitigate the risk of exposing users to cross-site scripting attacks, user data provided to web applications should always be sanitized, validated or escaped before rendered in a web browser.
Here are some examples of what HTML escaping looks like:
Output escaping can be achieved through various methods. One convenient, and usually safe, way is to rely on built-in mechanisms in web frameworks to automatically handle this for all output sent from the application.
However, most web frameworks allow developers to disable or bypass the built-in escaping mechanism. This makes sense when the data is already escaped, otherwise it would be escaped twice.
Whenever the built-in escaping is not used, it is important that there is another mechanism in place to handle either sanitization, validation or escaping of user provided data.
This rule flags code that disables or bypasses output escaping. The goal is to guide manual security code reviews.
- user data provided to the application is at some point sent back to the user with the purpose of being rendered in a browser.
- there is no mechanism to sanitize, validate or escape the data being sent from the application.
You may be at risk if you answered yes to the above questions.
- wherever an application is sending data meant to be rendered in a browser, make sure that any data influenced by the user is either sanitized, validated or escaped.
- use an appropriate encoding method for the context. For example, use HTML escaping for HTML element contexts, use attribute escaping for HTML attribute contexts, and so on. Read up to understand if the web framework you are using has automatic support for this or if it has to be achieved manually.
In addition to escaping dangerous strings, it is always a good idea to protect clients from third-party scripts:
- set the HttpOnly flag on any security-sensitive cookies to mitigate the risk of these cookies being stolen through cross-site scripting attacks.
- set a Content Security Policy (CSP) header to prevent many cross-site scripting attacks. For more information on how to set a CSP header, see this site.
- OWASP Cheat Sheet - XSS Prevention Cheat Sheet
- OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
- MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
- MITRE, CWE-80 - Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
- MITRE, CWE-81 - Improper Neutralization of Script in an Error Message Web Page
- MITRE, CWE-82 - Improper Neutralization of Script in Attributes of IMG Tags in a Web Page
- MITRE, CWE-83 - Improper Neutralization of Script in Attributes in a Web Page
- MITRE, CWE-84 - Improper Neutralization of Encoded URI Schemes in a Web Page
- MITRE, CWE-85 - Doubled Character XSS Manipulations
- MITRE, CWE-86 - Improper Neutralization of Invalid Characters in Identifiers in Web Pages
- MITRE, CWE-87 - Improper Neutralization of Alternate XSS Syntax
- SANS Top 25 - Insecure Interaction Between Components