In a previous post, I discussed the possibility of exposing Cross Site Scripting (XSS) vulnerabilities in your Meteor application through the use of jQuery components.

I gave an example where a malicious string with a <script> tag was being injected into the DOM through a call to $.html. For example:

$(...)
  .html("");

My recommendation in that post was to sanitize the string with Blaze._encode before injecting it into the DOM.

Another potential solution to this problem is to use the browser-policy Meteor package to establish a Content Security Policy (CSP) within your application. However, this solution comes with its share of quirks.

When CSP Falls Short

A Content Security Policy is used to tell the browser, among other things, what types of Javascript is allowed to run within a client’s browser, and what should be blocked.

Many applications instruct their Content Security Policy to disallow inline scripts (unsafe-inline). Inline scripts refer to any javascript that executes within an HTML element’s event handler attributes, within a <script> tag, or through the URL with a javascript: protocol.

It may seem like disallowing inline scripts would prevent our Cross Site Scripting issue. After all, the malicious Javascript is running from an inline <script> tag that’s being injected into the DOM.

However, in the eyes of the Content Security Policy, a <script> tag injected through a call to $.html is not considered an inline script.

Unexpected Unsafe-Eval

If your Content Security Policy disallows inline scripts, but allows Javascript evaluation (unsafe-eval), your application would still be vulnerable to this particular type of Cross Site Scripting attack.

Under the hood, this after-the-fact injection of a <script> tag, and its subsequent execution is considered an eval statement. Only by disallowing unsafe-eval can you prevent this type of XSS attack.

This is incredibly unintuitive and may lead to dangerous misunderstandings about what types of Javascript your application is allowed to execute. For a variety of reasons, some applications require the use of unsafe-eval. Without understanding the subtleties of what is considered an eval by your Content Security Policy, you may be vulnerable to severe Cross Site Scripting attacks.

It’s important to remember that a Content Security Policy is not a panacea against all front-end attacks. Instead, it’s a helpful safeguard that can be used in conjunction with other safeguards like properly sanitizing data, and validating user input.