Quando si parla di sicurezza di un sito web, spesso si pensa solo a password robuste e aggiornamenti regolari. Ma c’è un livello più profondo di protezione che passa quasi inosservato agli occhi degli utenti: gli HTTP Headers. Tra questi, uno dei più importanti per la sicurezza dei contenuti è la Content Security Policy (CSP).
Gli HTTP Headers sono stringhe di metadati che vengono inviate dal server al browser ogni volta che si carica una pagina. Possono controllare vari aspetti del comportamento del browser: come il sito viene renderizzato, da dove può caricare risorse esterne (come immagini, script, video), e quali comportamenti bloccare per prevenire attacchi come XSS (Cross Site Scripting), clickjacking, e altri.
La Content Security Policy è un header di sicurezza pensato per prevenire proprio attacchi XSS e altri tipi di injection, indicando al browser quali fonti di contenuti sono “fidate”. Se una risorsa (uno script, un’immagine, un video) proviene da una fonte non dichiarata nella CSP, il browser la blocca.
Tutto bello in teoria, ma nella pratica, quando si cerca di implementare una CSP su un sito WordPress complesso, magari costruito con page builder come Divi e plugin multilingua come WPML, ci si scontra con problemi di compatibilità, slider che non si caricano, video che spariscono e interi layout rotti.
In questa guida ti racconto una storia vera, fatta di test, errori, 505, slider spariti e soluzioni ragionate. Una specie di diario tecnico per chi vuole implementare una politica CSP efficace senza rompere il sito.
Fase 1: Messa in sicurezza con gli header base
Per migliorare la sicurezza del sito, si è cominciato implementando alcuni header fondamentali nel file .htaccess, posizionandoli dopo #END WordPress. Tra questi:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>
Il test su Security Headers è passato da una valutazione bassa a Grade A.
Fase 2: Aggiunta della Content Security Policy (CSP)
L’aggiunta della Content-Security-Policy ha richiesto più prove. Una delle prime versioni bloccava risorse importanti (CSS, immagini, JavaScript, video), rompendo completamente il layout del sito e facendo sparire elementi fondamentali come lo slider above the fold.
Si è quindi testata una versione della CSP più permissiva, ma funzionale, cercando il giusto compromesso tra sicurezza e compatibilità con Divi, WPML, video caricati da altri domini (ma comunque interni al gruppo di domini multilingua).
Fase 3: Il problema del video in homepage (solo su versioni estere)
Un bug specifico era legato al video inserito nello slider della home italiana e visualizzato sulle versioni estere (es. dominio .com, .de, .fr, .es). L’errore restituito dal browser:
Refused to load media from 'https://www.stracciogiusto.it/wp-content/uploads/...' because it violates the following Content Security Policy directive: "default-src 'self'".
La causa? La CSP non permetteva l’accesso alle risorse caricate dal dominio italiano.
Fase 4: CSP definitiva funzionante
Alla fine, la CSP è stata configurata correttamente per garantire:
- caricamento delle risorse da
selfe dahttps: - supporto a video e immagini anche da sottodomini (es. dominio italiano
stracciogiusto.it)
Ecco la versione definitiva e funzionante, inserita sempre dopo #END WordPress:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' https:; media-src 'self' https://www.stracciogiusto.it; connect-src 'self' https:; frame-src 'self' https:;"
</IfModule>
Il sito torna a funzionare perfettamente e il test restituisce nuovamente Grade A, con un solo avviso riguardo 'unsafe-inline' e 'unsafe-eval' (necessari per la compatibilità con Divi e altri script).
Conclusione tecnica: consigli pratici
- Testa su ambiente di staging: prima di modificare l’
.htaccess, prova le modifiche su un ambiente di test. - Inserisci sempre i blocchi dopo
#END WordPressper evitare conflitti. - Non usare una CSP troppo rigida se utilizzi Divi, WPML o builder simili.
- Aggiungi
media-srcse i video vengono caricati da un dominio diverso (es.www.stracciogiusto.it). - Valida la CSP con strumenti come CSP Evaluator.
- Monitora il caricamento delle risorse con la console del browser (tasto destro → ispeziona → Console).
Box riassuntivo: Header HTTP consigliati
| Header | Funzione |
|---|---|
| Strict-Transport-Security | Impone HTTPS per tutte le connessioni future |
| Referrer-Policy | Controlla i dati inviati nel referrer |
| X-Content-Type-Options | Impedisce MIME sniffing |
| X-Frame-Options | Blocca l’inserimento del sito in iframe |
| Permissions-Policy | Disattiva API del browser inutilizzate (es. microfono, fotocamera) |
| Content-Security-Policy | Impone da dove è possibile caricare risorse (script, video, immagini) |
Checklist PDF da scaricare
✅ Vuoi implementare una sicurezza avanzata sul tuo sito WordPress?
Scarica la checklist in PDF con:
- ✅ Header da copiare e incollare
- 🧪 Suggerimenti per testare
- 🛡️ Consigli per non rompere il sito
📄 Scarica la checklist completa (PDF)
Hai bisogno di una consulenza tecnica per mettere in sicurezza il tuo sito WordPress?
