Sweetalert: Compatibilidad con la política de seguridad del contenido

Creado en 11 oct. 2018  ·  8Comentarios  ·  Fuente: t4t5/sweetalert

En mi proyecto he dado la siguiente metaetiqueta (como se muestra en la captura de pantalla a continuación):

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

image

Cuando cargo la página, obtengo los siguientes errores en mi consola:

image

¿Alguien se enfrentó a este problema antes?

Además, por cierto, el nombre de mi archivo js es sweetalert.min.js, ¡pero el contenido del archivo contiene los js no minificados!

Comentario más útil

La solución es agregar los hash a su encabezado Content-Security-Policy .

Algo como

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

No es ideal, pero es mejor que unsafe-inline . El problema es que si los archivos cambian, los hash ya no coincidirán y el navegador los rechazará.

La situación ideal sería extraer el CSS en su propio archivo y alojarlo en un CDN. De esa forma podemos poner el archivo en una lista blanca.

Todos 8 comentarios

Debe actualizar el valor de Content-Security-Policy para adaptarse a la directiva style-src que debe contener 'inseguro-en línea' (tenga cuidado de citar) para ejecutar los estilos en línea inyectados.

Definitivamente no es ideal forzar a los desarrolladores a usar la política unsafe-inline para CSS. Quizás deberíamos encontrar una mejor manera de manejar esto.

Una forma es no importar el archivo css dentro de su código y hacerlo disponible como un archivo separado que se puede importar dentro del código del desarrollador. algo como
import 'sweetalert/sweetalert.css
De esta manera, sería responsabilidad del desarrollador asegurarse de que no infrinja CSP

No tiene (casi) nada que ver con dónde está el archivo CSS (siempre que el CSS resida en el mismo dominio). Sweetalert _injects_ inline CSS , que cualquier CSP que valga la pena no permitirá a menos que haya un valor nonce / hash. Me está causando un sinfín de dolor esta mañana; Puede que tenga que desconectarlo de mi proyecto, lo cual es una pena, porque realmente me gusta (d).

¿Ha habido alguna actualización sobre esto? Tengo el mismo problema; ¿Me pregunto cuál es la mejor manera de evitar esto?

La solución es agregar los hash a su encabezado Content-Security-Policy .

Algo como

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

No es ideal, pero es mejor que unsafe-inline . El problema es que si los archivos cambian, los hash ya no coincidirán y el navegador los rechazará.

La situación ideal sería extraer el CSS en su propio archivo y alojarlo en un CDN. De esa forma podemos poner el archivo en una lista blanca.

No tiene (casi) nada que ver con dónde está el archivo CSS (siempre que el CSS resida en el mismo dominio). Sweetalert _injects_ inline CSS , que cualquier CSP que valga la pena no permitirá a menos que haya un valor nonce / hash. Me está causando un sinfín de dolor esta mañana; Puede que tenga que desconectarlo de mi proyecto, lo cual es una pena, porque realmente me gusta (d).

aquí igual.

Puedo obtener dos hashes de estilo en línea de sweetalert.min.js en Chrome. Cuando se agrega al encabezado CSP, Chrome ya no se queja.
Pero Firefox y Safari siguen quejándose y no puedo encontrar el hash adecuado. Estos navegadores no dan ninguna pista.
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.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

Lusitaniae picture Lusitaniae  ·  4Comentarios

voodoo6 picture voodoo6  ·  4Comentarios

adiwithadidas picture adiwithadidas  ·  4Comentarios

fracz picture fracz  ·  4Comentarios

rapeflower picture rapeflower  ·  4Comentarios