Sweetalert: Content Security Policy Compatibility

Created on 11 Oct 2018 · 8Comments · Source: t4t5/sweetalert

In my project I have given the following meta tag (as shown in the screenshot followed):

<meta http-equiv="Content-Security-Policy" content="default-src http:">

When I load the page I get the following errors in my console:

Anyone faced this issue before?

Also BTW the name of my js file is sweetalert.min.js but the file content contains the unminified js!

Source

adhip94

Most helpful comment

The workaround is to add the hashes to your Content-Security-Policy header.

Something like

style-src 'self' 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=' 'sha256-wTr/bct+DGhJCU0mVZOm9Z1v99oBZrIu4VCMYQJWdfI=';

Not ideal but it is better than unsafe-inline. Issue is that if the files change, the hashes will no longer match and the browser will reject them.

The ideal situation would be to extract the css into it's own file and host it on a CDN. That way we can white list the file.

yarrgh on 8 Jul 2019

👍3

All 8 comments

You need to update the Content-Security-Policy value to accommodate the style-src directive which must contain 'unsafe-inline' (careful to quote around) to execute the inline styles injected.

maksbd19 on 13 Oct 2018

👎1

It's definitely not ideal to force developers to use the unsafe-inline policy for CSS. We should maybe find a better way to handle this.

t4t5 on 27 Oct 2018

One way is to not to import the css file inside your code and make it available as a separate file that can be imported within the developer code. something like
import 'sweetalert/sweetalert.css
This way it would be the responsibility of developer to make sure it does not violate CSP

kikoanis on 15 Dec 2018

👎2

It's got (almost) nothing to do with where the CSS file is (as long as the CSS resides on the same domain). Sweetalert _injects_ inline CSS, which any CSP worth having will not allow unless there's a nonce/hash value. It's causing me no end of pain this morning; I may have to unwire it from my project, which is a shame, because I really like(d) it.

kvn1234 on 14 Feb 2019

Have there been any updates on this? I am having the same issue; just wondering what the best way to get around this is?

sleepingMantis on 1 May 2019

The workaround is to add the hashes to your Content-Security-Policy header.

Something like

style-src 'self' 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=' 'sha256-wTr/bct+DGhJCU0mVZOm9Z1v99oBZrIu4VCMYQJWdfI=';

Not ideal but it is better than unsafe-inline. Issue is that if the files change, the hashes will no longer match and the browser will reject them.

The ideal situation would be to extract the css into it's own file and host it on a CDN. That way we can white list the file.

yarrgh on 8 Jul 2019

👍3

It's got (almost) nothing to do with where the CSS file is (as long as the CSS resides on the same domain). Sweetalert _injects_ inline CSS, which any CSP worth having will not allow unless there's a nonce/hash value. It's causing me no end of pain this morning; I may have to unwire it from my project, which is a shame, because I really like(d) it.

same here.

rbcabreraUPM on 15 Oct 2019

I can get two inline style hashes from sweetalert.min.js in Chrome. When added to the CSP header, Chrome doesn't complain anymore.
But Firefox and Safari still complain, and I am not able to find the proper hash. These browsers don't give any hints.
Firefox: Content Security Policy: The page’s settings blocked the loading of a resource at inline (“style-src”)
Safari: Refused to apply a stylesheet because its hash, its nonce, or 'unsafe-inline' does not appear in the style-src directive of the Content Security Policy.