Il sigillo HTTP: la riga che decide chi entra nella pagina
Nel 2011 Mozilla spedì ai browser una riga nuova: X-Content-Security-Policy. Una lista scritta sulla soglia della pagina, non un firewall.
Nel marzo 2011, con Firefox 4, Mozilla spedì ai browser una riga nuova nell'header della risposta HTTP: X-Content-Security-Policy. Non era ancora uno standard. Era un prototipo. Brandon Sterne e Sid Stamm lo avevano costruito a partire da un'idea discussa almeno dal 2007, tra Gervase Markham e il ricercatore Robert Hansen: lasciare che una pagina dichiari, in chiaro, da quali origini il browser può caricare script, immagini, frame, connessioni.
Nel giugno 2009 Mozilla aveva già raccontato il problema in un post noto: il XSS funziona perché tutto ciò che arriva nella risposta del server viene trattato con lo stesso privilegio. Uno script iniettato e uno script legittimo condividono lo stesso contesto. La Content Security Policy, in quella bozza, imponeva due regole semplici: il JavaScript doveva stare in file esterni, e quei file dovevano venire da host esplicitamente approvati. Il resto — gli script inline, gli URI javascript:, gli attributi di evento — andava ignorato.
La soglia scritta
Nel novembre 2011 il W3C pubblicò la prima Working Draft di Content Security Policy 1.0. La sintassi era già diversa da quella sperimentale di Firefox. Un anno dopo, nel novembre 2012, la specifica raggiunse lo stato di Candidate Recommendation. Chrome aveva spedito un'implementazione prefissata nell'agosto 2011; con Chrome 25 adottò l'header non prefissato. Firefox 23, nel giugno 2013, fece lo stesso: da X-Content-Security-Policy a Content-Security-Policy.
Qui il mito tocca l'oggetto e si ferma. L'oggetto non è un algoritmo, non è un firewall, non è un badge di conformità. È una riga. Una lista. Un elenco di origini ammesso, inviato insieme alla pagina, che il browser legge prima di caricare qualunque altra cosa. La soglia non sta nel seminterrato del data center: sta nella risposta stessa, stampata sopra il documento come un sigillo.
Ciò che non è nella lista
Il vantaggio più citato resta quello iniziale: se la policy rifiuta gli script inline, gran parte delle iniezioni XSS classiche smette di funzionare anche quando un bug di escape è ancora lì. Non è magia. È un rifiuto esplicito. Il browser non indovina chi è fidato: legge la lista. Ciò che non è scritto non entra.
È la stessa grammatica che, in un altro registro, chiamo abitudine operativa. Nel saggio La sicurezza come abitudine operativa scrivo che la sicurezza buona non nasce dall'ansia, nasce da procedure chiare prima dell'emergenza. Una CSP è una di quelle procedure: non protegge perché è sofisticata, protegge perché è dichiarata in anticipo, e perché il browser la applica senza chiedere scuse.
Sul sito tengo uno generatore di Content Security Policy e un controllo degli header di sicurezza: non perché una riga basti, ma perché senza quella riga il resto della disciplina resta cieco. La pagina che non dice chi può entrare lascia entrare chiunque sembri appartenere alla risposta. Il sigillo non è un ornamento. È l'unica soglia che il browser riconosce ancora come tale.
Fonti: Mozilla Security Blog, «Content Security Policy 1.0 Lands In Firefox», 11 giugno 2013; Mozilla Security Blog, «Shutting Down XSS with Content Security Policy», 19 giugno 2009; W3C, Content Security Policy 1.0 (Working Group Note, 19 febbraio 2015); Wikipedia, Content Security Policy (consultata il 5 novembre 2026).
> ln -s ./linked-nodes
- [PARTE DI] Cyberinfrastruttura Operativa
- [CORRELATO] CSP Generator
- [CORRELATO] La sicurezza come abitudine operativa