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:
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
Many applications instruct their Content Security Policy to disallow inline scripts (
<script> tag, or through the URL with a
<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.
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.
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.