En absoluto.
Digamos que construyo mi sitio web supersite.com con una gran cantidad de JS, por lo que quiero que sea capaz de ejecutar scripts, pero también quiero agregar algunos agregados, pero no quiero que sea dinámico y por lo tanto no ejecuta script .
El problema es que, por lo general, mi proveedor de complementos incluye el script. Para evitar esto, le digo explícitamente que no quiero un script, luego estableceré el siguiente iframe :
<iframe src="http://addprovider.com/?site=mywebsite"csp="script-src 'none'"></iframe>
Al enviar la solicitud GET a addprovider.com , se establecerá el siguiente encabezado:
Embedding-CSP: script-src 'none'
A partir de ahí, addprovider.com sabe que si pone script , supersite.com se negará a ejecutar el script y, por lo tanto, decidirá colocar algunas imágenes extravagantes. Al devolver la respuesta, addprovider.com muestra que acepta la política dada al configurar el siguiente encabezado:
Content-Security-Policy: script-src 'none'
Si addprovider.com intenta hacer trampa y devolver que su respuesta es compatible con csp pero no lo hace, supersite.com la respuesta se bloqueará.
Si addprovider no devuelve csp o devuelve un csp que no coincide o no aplica el csp dado, la respuesta también se bloqueará.
¿Cómo es útil? Estas son las 2 alternativas atm:
-
Establezca un CSP en supersite.com , con encabezado o etiqueta meta: <meta http-equiv="Content-Security-Policy" content="script-src 'self'"> . Sin embargo, este CSP no se aplicará al addprovider.com incrustado!
-
Usa los atributos sandbox . Sin embargo, esto es demasiado amplio. Solo puedes bloquear todos los script o ninguno. No puedes especificar ubicaciones diferentes mientras puedes hacerlo con CSP