XSS prevention for ExpressJS
This is a cross-site scripting (XSS) prevention cheat sheet by Semgrep, Inc. It contains code patterns of potential XSS in an application. Instead of scrutinizing code for exploitable vulnerabilities, the recommendations in this cheat sheet pave a safe road for developers that mitigate the possibility of XSS in your code. By following these recommendations, you can be reasonably sure your code is free of XSS.
Mitigation summary
In general, always use a template engine and res.render() to render HTML content. Some common template engines include Pug, Mustache, and EJS. If you need HTML escaping, escape the content. Try to do so in JavaScript code if possible. Review each individual case carefully. Once reviewed, exempt the finding with # nosemgrep. Beware of putting data in dangerous locations such as in script tags. And as always, run a security checker on your code.
Check your project using Semgrep
The following command runs an optimized set of rules for your project:
semgrep --config p/default
1. Server code: Bypassing the template engine
1.A. Direct use of res.send()
Writing directly to the response object bypasses the template engine which means content will not be autoescaped. This could introduce a XSS vulnerability.
Example:
res.send("<div>" + user.name + "</div>")
References
Mitigation
Ban res.send(). Alternatively, use a template engine and call res.render().
Semgrep rule
javascript.express.security.audit.xss.direct-response-write.direct-response-write1.B. Direct use of res.write()
Writing directly to the response object bypasses the template engine which means content will not be autoescaped. This could introduce a XSS vulnerability.
Example:
res.write("<div>" + user.name + "</div>")
References
- Sanitizers required when sending data via
res.send() response.write()documentation- Differences between
res.send()andres.write()
Mitigation
Ban response.write(). Alternatively, use a template engine and call res.render().
Semgrep rule
javascript.express.security.audit.xss.direct-response-write.direct-response-write1.C. Mustache: overwriting the global escape function
Mustache.escape() is the global escape function for Mustache. If this is overwritten, escaping may not happen properly and this could introduce XSS vulnerabilities.
Example:
Mustache.escape = function(text) {return text;};
References
Mitigation
Ban overwriting Mustache.escape. If necessary, use triple braces to escape only what you need in the template. Review each usage carefully and exempt with <!-- nosemgrepgrep -->.
Semgrep rule
javascript.express.security.audit.xss.mustache.escape-function-overwrite.escape-function-overwrite2. Templates: Variable explicitly unescaped
2.A. Mustache: Triple braces {{{ ... }}}
Triple braces disables escaping for the content inside. This could expose your application to XSS vulnerabilities.
Example:
{{{ user_name }}}
References
Mitigation:
Ban triple braces. Alternatively, only use this if necessary. Review each usage carefully and exempt with <!-- nosemgrep -->.
Semgrep rule
javascript.express.security.audit.xss.mustache.explicit-unescape.template-explicit-unescape2.B. Mustache: Ampersand &
The ampersand disables escaping for the following variable. This could expose your application to XSS vulnerabilities.
Example:
{{ &user_name }}
References
Mitigation
Ban ampersand escaping in template expressions. Alternatively, prefer triple braces, if necessary.
Semgrep rule
javascript.express.security.audit.xss.mustache.explicit-unescape.template-explicit-unescape2.C. Pug: The unescape operator, !=
The unescape operator, !=, disables HTML escaping for the content. This permits raw HTML to be rendered in a template, which could create a XSS vulnerability.
Example:
a(href!=url) Documentation
References
Mitigation
Ban !=; it is rarely necessary. Often, you want !{...}. If you must use this, review each usage carefully and exempt with <!-- nosemgrep -->.
Semgrep rule
javascript.express.security.audit.xss.pug.explicit-unescape.template-explicit-unescape2.D. Pug: Unescaped strings with !{ ... }
!{...} disables HTML escaping for the content. This permits raw HTML to be rendered in a template, which could create a XSS vulnerability.
Example:
p Joel: !{riskyBusiness}
References
Mitigation:
Ban !{...}. Alternatively, only use this if necessary. Review each usage carefully and exempt with <!-- nosemgrep -->.
Semgrep rule
javascript.express.security.audit.xss.pug.explicit-unescape.template-explicit-unescape2.E Pug: And-attributes, $attributes(...)
The &attributes(...) syntax explodes an object into attributes of an element. Attributes are not automatically escaped using this method. This permits raw HTML to be rendered in a template, which could create a XSS vulnerability.
Example:
div#foo(data-bar='foo')&attributes({'data-foo': 'bar'})
References
Mitigation
Ban &attributes(...). Alternatively, prefer != only if necessary.
Semgrep rule
javascript.express.security.audit.xss.pug.and-attributes.template-and-attributes2.F. EJS: Unescaped content, <%- ... %>
A hyphen instead of an equals in EJS expressions disables escaping for the content inside. This could expose your application to XSS vulnerabilities.
Example:
<div><%- user.name %></div>
References
Mitigation
Ban <%- ... %>. Alternatively, only use it if necessary. Review each usage carefully and exempt with <!-- nosemgrep -->.
Semgrep rule
javascript.express.security.audit.xss.ejs.explicit-unescape.template-explicit-unescape3. Templates: Variable in dangerous location
3.A. Mustache: Unquoted variable in HTML attribute
Unquoted template variables rendered into HTML attributes is a potential XSS vector because an attacker could inject JavaScript handlers which do not require HTML characters. An example handler might look like: onmouseover=alert(1). HTML escaping will not mitigate this. The variable must be quoted to avoid this.
Eexample:
<div class={{ classes }}></div>
References
Mitigation
'Flag unquoted HTML attributes with Mustache expressions. Alternatively, always use quotes around HTML attributes.
3.B. EJS: Unquoted variable in HTML attribute
Unquoted template variables rendered into HTML attributes is a potential XSS vector because an attacker could inject JavaScript handlers which do not require HTML characters. An example handler might look like: onmouseover=alert(1). HTML escaping will not mitigate this. The variable must be quoted to avoid this.
Example:
<div class=<%= classes %>></div>
References
Mitigation
Flag unquoted HTML attributes with EJS expressions. Alternatively, always use quotes around HTML attributes.
3.C. Mustache: Variable in href attribute
Template variables in a href value could still accept the javascript: URI. This could be a XSS vulnerability. HTML escaping will not prevent this. Begin links with a forward slash '/' prior to the template expression to generate dynamic links: <a href="/{{ url }}}">
Example:
<a href="{{ url }}">
References
Mitigation
Flag template variables in href attributes. Alternatively, use a literal forward slash preceding the template expression to generate relative links.
Semgrep rule
javascript.express.security.audit.xss.mustache.var-in-href.var-in-href3.D. Pug: Variable in href attribute
Template variables in a href value could still accept the javascript: URI. This could be a XSS vulnerability. HTML escaping will not prevent this. Begin links with a forward slash '/' prior to the template expression to generate dynamic links: a(href='/' + link)="hello"
Example:
a(href=link)="hello"
References
Mitigation
Flag template variables in href attributes. Alternatively, append the link to a literal forward slash to forcibly generate relative links.
Semgrep rule
javascript.express.security.audit.xss.pug.var-in-href.var-in-href3.E. EJS: Variable in href attribute
Template variables in a href value could still accept the javascript: URI. This could be a XSS vulnerability. HTML escaping will not prevent this. Begin links with a forward slash '/' prior to the template expression to generate dynamic links: <a href="/<%= link %>">
Example:
<a href="<%= link %>"></a>
References
Mitigation
Flag template variables in href attributes. Alternatively, use a literal forward slash preceding the template expression to generate relative links.
Semgrep rule
javascript.express.security.audit.xss.ejs.var-in-href.var-in-href3.F. Mustache: Variable in <script> block
Template variables placed directly into JavaScript or similar are now directly in a code execution context. Normal HTML escaping will not prevent the possibility of code injection because code can be written without HTML characters. This creates the potential for XSS vulnerabilities, or worse.
Example:
<script>var name = {{ name }};</script>
References
- Template engines: Why default encoders are not enough
- Protecting against XSS in Rails - JavaScript contexts. (Relevant to all template engines.)
Mitigation
Ban template variables in <script> blocks. Alternatively, avoid wherever possible. If absolutely necessary, locate a JavaScript encoding library and enforce its usage.
Semgrep rule
javascript.express.security.audit.xss.mustache.var-in-script-tag.var-in-script-tag3.G. Pug: Variable in <script> block
Template variables placed directly into JavaScript or similar are now directly in a code execution context. Normal HTML escaping will not prevent the possibility of code injection because code can be written without HTML characters. This creates the potential for XSS vulnerabilities, or worse.
Example:
script(type="text/javascript")="a += " + a
References
- Template engines: Why default encoders are not enough
- Protecting against XSS in Rails - JavaScript contexts. (Relevant to all template engines.)
Mitigation
Ban template variables in <script> blocks. Alternatively, avoid wherever possible. If absolutely necessary, locate a JavaScript encoding library and enforce its usage.
Semgrep rule
javascript.express.security.audit.xss.pug.var-in-script-tag.var-in-script-tag3.H. EJS: Variable in <script> block
Template variables placed directly into JavaScript or similar are now directly in a code execution context. Normal HTML escaping will not prevent the possibility of code injection because code can be written without HTML characters. This creates the potential for XSS vulnerabilities, or worse.
Example:
<script>var name = <%= name %>;</script>
References
- Template engines: Why default encoders are not enough
- Protecting against XSS in Rails - JavaScript contexts. (Relevant to all template engines.)
Mitigation
Ban template variables in <script> blocks. Alternatively, avoid wherever possible. If absolutely necessary, locate a JavaScript encoding library and enforce its usage.