Content Security Policy: guida introduttiva per WordPress

Questa guida approfondisce Content Security Policy WordPress con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

Il modo più prudente per iniziare è Content-Security-Policy-Report-Only, che registra le violazioni senza applicare il blocco. I report vanno analizzati e non copiati automaticamente nella policy.

WordPress, page builder e plugin possono usare script inline, stili inline, CDN, font e servizi esterni. `unsafe-inline` semplifica ma riduce la protezione; nonce e hash richiedono integrazione più accurata.

Come riconoscere il problema

• Dopo CSP mancano script o stili.
• Checkout o form non funzionano.
• La console mostra Refused to load.
• Report-Only registra molte origini.
• Iframe e font vengono bloccati.

Cause più frequenti

1. default-src troppo restrittivo

Le risorse non hanno direttive specifiche. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Script inline

Tema o plugin richiedono nonce, hash o unsafe-inline. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. Servizi esterni

Analytics, mappe, pagamenti e font usano più domini. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. Iframe

frame-src non autorizza il provider. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. Dati e blob

Immagini o worker richiedono schemi specifici. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Header duplicati

CDN, plugin e server applicano policy diverse. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

1. Inventaria le risorse. Usa DevTools e Network. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Attiva Report-Only. Raccogli violazioni senza interrompere il sito. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Raggruppa per direttiva. script-src, style-src, img-src, font-src, connect-src e frame-src. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Controlla tutte le funzioni. Login, editor, form, pagamenti e area riservata. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Identifica script inline. Valuta nonce o hash. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Controlla header duplicati. Una policy aggiuntiva può restringere ulteriormente. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Filtra report rumorosi. Estensioni browser possono generare violazioni non del sito. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

1. Definisci default-src ‘self’ come base valutata. Aggiungi direttive specifiche. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Autorizza soltanto origini necessarie. Evita wildcard ampie. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Usa nonce o hash quando integrabile. Riduci dipendenza da unsafe-inline. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Gestisci CDN e API. Aggiungi le origini nei contesti corretti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Testa in Report-Only. Passa all’enforcement per fasi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Mantieni una sola policy. Coordina CDN, server e plugin. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Monitora dopo aggiornamenti. Nuovi plugin possono introdurre risorse. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Controlli finali

• Console senza blocchi imprevisti.
• Form e checkout funzionano.
• Policy unica.
• Origini limitate.
• Report monitorati.

Prevenzione

• Staging.
• Report-Only.
• Inventario servizi.
• Policy versionata.
• Test dopo aggiornamenti.

Errori da evitare

• Non copiare una CSP generica direttamente in produzione.
• Non usare wildcard ovunque.
• Non ignorare wp-admin e checkout.
• Non aggiungere unsafe-eval senza motivo.
• Non applicare più header incoerenti.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

• URL
• header CSP
• violazione console
• funzione bloccata
• plugin o servizio esterno

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• MDN Content-Security-Policy
• W3C CSP Level 3

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su Content Security Policy WordPress