Indice dei contenuti
Quando si parla di sicurezza web, pensiamo subito a password robuste, aggiornamenti e firewall. Tutte cose importanti. Ma esiste un altro livello di protezione che lavora direttamente nel browser: la Content Security Policy, o CSP. 🧱
È uno strumento potente, ma ha una reputazione meritata: se lo configuri di fretta, puoi ritrovarti con un sito apparentemente intatto e una serie di funzionalità che non funzionano più. Moduli, analytics, font, video incorporati e script di terze parti sono spesso i primi a risentirne.
Che cos’è la CSP, spiegata senza complicazioni
La Content Security Policy è una politica che il server comunica al browser, normalmente tramite un header HTTP. Indica da quali origini è consentito caricare determinate risorse e, con direttive specifiche, quali script possono essere eseguiti.
Un esempio volutamente minimale:
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'Questa configurazione non è una ricetta pronta da incollare: può bloccare risorse necessarie al tuo sito. Serve soltanto a capire la logica. 'self' indica la stessa origine della pagina; object-src 'none' vieta i contenuti gestiti tramite elementi come object; base-uri 'self' limita l’origine utilizzabile dall’elemento base.
Perché è utile contro alcuni attacchi XSS 🔐
Un attacco Cross-Site Scripting, o XSS, prova a far eseguire al browser codice non previsto dalla pagina. La CSP può limitare l’esecuzione di script non autorizzati e ridurre l’impatto di alcune vulnerabilità. Non sostituisce però l’escaping dell’output, la validazione degli input o gli aggiornamenti delle librerie.
La difesa migliore è a strati: correggere la vulnerabilità nell’applicazione e usare la CSP come protezione aggiuntiva. È lo stesso principio che applico quando parlo di upload sicuro dei file e di gestione dei privilegi.
Il problema degli script inline e dei page builder ⚙️
Molti siti WordPress utilizzano script inline, stili generati dinamicamente e risorse caricate da plugin. Una politica restrittiva può bloccarli. La scorciatoia di aggiungere indiscriminatamente 'unsafe-inline' alla direttiva degli script rende la configurazione più permissiva e ne riduce una parte importante dei benefici.
Per gli script si possono usare nonce generati per risposta oppure hash del contenuto autorizzato. Sono soluzioni più robuste, ma richiedono integrazione con il modo in cui il sito produce HTML. Su WordPress, soprattutto con page builder e plugin eterogenei, non sempre è una modifica da applicare con una singola riga nel file di configurazione.
Report-Only: il modo sensato di iniziare 🧪
La prima cosa che farei su un sito esistente è attivare una politica in modalità di osservazione, usando l’header Content-Security-Policy-Report-Only. Il browser rileva le violazioni senza applicare i blocchi della nuova politica. In questo modo puoi capire quali risorse verrebbero rifiutate prima di compromettere l’esperienza degli utenti.
Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'È un punto di partenza per i test, non una politica definitiva. Per raccogliere report in modo centralizzato occorre configurare anche un endpoint di reporting appropriato; in alternativa puoi iniziare osservando la console del browser durante una sessione di collaudo.
Una procedura pratica per WordPress 🛠️
- Inventariare le risorse caricate: script, CSS, font, immagini, iframe e servizi esterni.
- Provare una prima politica in Report-Only su un ambiente di staging.
- Testare homepage, articoli, moduli, login e funzionalità dinamiche.
- Analizzare ogni violazione e distinguere risorse legittime da quelle non necessarie.
- Valutare nonce o hash per gli script inline quando l’architettura lo permette.
- Applicare gradualmente la politica effettiva e monitorare eventuali regressioni.
Il passaggio nello staging WordPress è particolarmente importante. Una CSP che sembra funzionare su una pagina statica potrebbe impedire il caricamento di un modulo o di un’interfaccia amministrativa.
CSP e CDN: attenzione alle origini esterne ☁️
Se usi una CDN, un servizio di analytics, un player video o font remoti, devi verificare le origini effettivamente utilizzate. Aggiungere un dominio a script-src non equivale a consentirlo per tutte le altre tipologie di risorse: direttive come img-src, style-src, font-src e connect-src hanno scopi diversi.
Non allargherei la policy a interi domini soltanto per far sparire gli avvisi. Ogni eccezione dovrebbe avere una ragione chiara, perché una lista di autorizzazioni troppo ampia riduce il valore della protezione.
Gli errori da evitare ❌
- Applicare una CSP rigida direttamente in produzione senza test.
- Considerare CSP un sostituto delle correzioni contro XSS.
- Usare autorizzazioni molto permissive per risolvere rapidamente i problemi.
- Testare soltanto la homepage e dimenticare checkout, login o moduli.
- Ignorare i report dopo l’attivazione.
Una buona Content Security Policy è il risultato di un percorso di osservazione e affinamento, non di un copia-incolla. Per i dettagli delle direttive e degli esempi aggiornati, il riferimento che consiglio è la guida CSP di MDN.
La sicurezza web non consiste nel bloccare tutto: consiste nel consentire soltanto ciò che serve, sapendo perché serve. 🙂