Verifica dell'intestazione CSP
Basta incollare il valore dell'intestazione Content-Security-Policy per convalidarne in blocco direttive e sorgenti. Rileva le impostazioni pericolose come unsafe-inline, la mancanza di default-src e gli errori di digitazione nei nomi delle direttive, mostrando in modo chiaro le sorgenti ammesse per ciascuna.
Consigli
- La politica si distribuisce di norma come intestazione della risposta HTTP, ma la si può indicare anche con il marcatore
<meta http-equiv="Content-Security-Policy">; alcune direttive, come quella per le segnalazioni, non funzionano però nel metadato. - Prima di applicarla direttamente in produzione, conviene raccogliere le sole segnalazioni di violazione con l'intestazione in sola segnalazione, verificare l'impatto sulle funzioni esistenti e passare poi all'applicazione effettiva.
- Il carattere jolly e il valore 'unsafe-inline' facilitano le prove di funzionamento ma compromettono gravemente l'efficacia della politica contro gli attacchi di scripting fra siti: le impostazioni permissive usate in sviluppo vanno sempre restrette prima della pubblicazione.
- Scrivendo più volte la stessa direttiva vale soltanto la prima. Per aggiungere o sostituire impostazioni occorre riunire le sorgenti in un'unica direttiva.
- Nella console degli strumenti per sviluppatori del navigatore, le risorse bloccate dalla politica compaiono in rosso con un messaggio di rifiuto: è il primo posto da controllare durante la messa a punto.
Domande frequenti
A proposito — perché è nata la politica di sicurezza dei contenuti, ossia la storia di una difesa che la sola cura nell'uscita non bastava a garantire
La politica di sicurezza dei contenuti nasce da un'idea proposta intorno al 2004 da Robert Hansen, sviluppata in specifica a partire dal 2008 circa soprattutto da Brandon Sterne, ingegnere di Mozilla, e formalizzata nel 2012 come prima raccomandazione candidata del consorzio del web. All'epoca, fra le vulnerabilità delle applicazioni web, gli attacchi di scripting fra siti erano considerati i più gravi, e ci si rese conto che affidarsi soltanto alla diligenza di chi programma nel proteggere ogni uscita aveva dei limiti: nacque così un meccanismo di difesa a più strati, che impone dal lato del navigatore un limite all'origine degli script eseguibili.
Con la seconda versione della specifica si introdusse l'autorizzazione degli script incorporati tramite numero d'uso unico o sintesi, che permette di consentirne alcuni senza ricorrere a 'unsafe-inline'. La terza versione ha aggiunto la parola chiave che considera automaticamente attendibili gli script figli caricati da uno script già attendibile, riducendo di molto il costo di manutenzione degli elenchi di autorizzazione nei siti di grandi dimensioni.
Google lavora da tempo per introdurre nei propri servizi una politica rigorosa fondata sui numeri d'uso unici e da quell'esperienza ha pubblicato una ricerca secondo cui le politiche basate su elenchi di nomi host si aggirano facilmente, mentre quelle fondate su numeri d'uso unici e sintesi sono assai più efficaci. Quelle conclusioni sono oggi ampiamente citate come buona pratica e mostrano quanto conti non soltanto vietare i valori pericolosi, ma decidere fin dall'inizio su quale metodo fondare le autorizzazioni.