Assolutamente no.
Diciamo che costruisco il mio sito web supersite.com con un sacco di JS, quindi voglio che sia in grado di eseguire script, ma voglio anche aggiungerne alcuni, ma non voglio che sia dinamico e quindi non esegue script .
Il problema è che di solito il mio add service include lo script. Per evitare questo, gli dico esplicitamente che non voglio script, quindi imposterò il seguente iframe :
<iframe src="http://addprovider.com/?site=mywebsite"csp="script-src 'none'"></iframe>
Durante l'invio della richiesta GET a addprovider.com , verrà impostata la seguente intestazione:
Embedding-CSP: script-src 'none'
Da lì, addprovider.com sa che se mette script , supersite.com si rifiuterà di eseguire lo script e quindi deciderà di mettere invece delle immagini fantasiose. Durante l'invio della risposta, addprovider.com mostra che accetta la politica data impostando la seguente intestazione:
Content-Security-Policy: script-src 'none'
Se addprovider.com tenta di imbrogliare e rispedire che la sua risposta è csp complient ma non, supersite.com la risposta verrà bloccata.
Se addprovider non restituisce csp o restituisce un csp che non corrisponde o impone il dato csp , anche la risposta verrà bloccata.
Come è utile? Queste sono le 2 alternative atm:
-
Imposta CSP su supersite.com , con intestazione o meta tag: <meta http-equiv="Content-Security-Policy" content="script-src 'self'"> . In ogni caso, questo CSP non si applicherà al addprovider.com incorporato!
-
Utilizza gli attributi di sandbox . Comunque, questo è troppo ampio. Puoi solo bloccare tutto script o nessuno. Non puoi specificare località diverse mentre puoi fare con CSP