Content Security Policy violation: inline styles unsafe

[mholt]

Trying out this fork just to compare with the original thing. I do notice this (and the original might have this issue too, I forgot to check):

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-ZdHxw9eWtnxUb3mk6tBS+gIiVUPE3pGM470keHPDFlE='), or a nonce ('nonce-...') is required to enable inline execution.

I could just hash the contents but I don't want to have to update the server configuration (CSP header) every time I update SWAL.

[limonte]

For bug reports, please include a jsfiddle in order for us to be able to reproduce the issue.

JSFiddle template: https://jsfiddle.net/limon/ad3quksn/

[mholt]

I can't. Unless I can tell JSFiddle which headers to send back from the server. Any CSP that doesn't allow "unsafe-inline" (which is an arguably bad CSP - see https://securityheaders.io) will block it from running.

[birjj]

@limonte It's impossible (or, really hard) to reproduce on JSFiddle, since it requires the Content-Security-Policy HTTP header to be set.

The CSP rule blocks inline styles, but not CSSOM (eg. blocks <div style="..."> but not div.style.top = ...). The only place I could find that uses inline styles is defaults.js#L51.

The main problem here is testing it. It would require setting up a server that serves files with the proper HTTP headers, and some code to load it. I'll look into fixing this.

[mholt]

Thanks @birjolaxew 😄 FWIW, I would recommend Caddy (disclaimer: author); it runs everywhere without trouble and is very easy to set this header. In fact, just put this in a file called Caddyfile and run caddy from the folder:

localhost

header / {
	Content-Security-Policy "style-src 'self'; script-src https://www.google-analytics 'self' data: blob: https:; img-src 'self' data: https:; font-src 'self' https: data: blob:; media-src 'self' https: data: blob:; connect-src 'self' https:; object-src 'none';"
	X-Frame-Options        SAMEORIGIN
	X-Content-Type-Options nosniff
	X-XSS-Protection       "1; mode=block"
}

These are the security-related headers I'm currently using. Basically, you just need to un-inline the style="" CSS and put it in the CSS file instead.

[mholt]

Awesome - thanks!

[limonte]

@mholt Should be fixed in v6.2.8, please take a look.

[mholt]

Works great - thank you!

[limonte]

All credits to @birjolaxew - he's the rockstar of this plugin 🎸

[ekoome]

getting same issue with v7.12.9

sweetalert2.all.js:2001 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' data: gap://ready". Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

[limonte]

@ekoome

It looks like for you project you need to include CSS styles manually:

<script src="sweetalert2.min.js"></script>
<link rel="stylesheet" href="sweetalert2.min.css">

[binarious]

@limonte I'm having the same issue with 7.25.6 and webpack.

My code:

import Swal from 'sweetalert2'
Swal({ ... });

Error:

Also tried adding styles separately with @import '~sweetalert2/dist/sweetalert2.min.css'; in my scss files.

[limonte]

@binarious try this:

// import sweetalert2 without inline styles
import swal from 'sweetalert2/dist/sweetalert2.js'

// import styles separately
import 'sweetalert2/dist/sweetalert2.css'

[BenceSzalai]

README.md could be more explicit about the difference between sweetalert2.js and sweetalert2.all.js. Once is is pointed out in such context as above, it seems obvious, but before that, it is very subtle. Or is this a common pattern I'm not aware of?