Content Security Policy: guida introduttiva per WordPress

In breve: Content Security Policy: WordPress permette di limitare le origini autorizzate per script, stili, immagini, font, frame e altre risorse.

Riferimenti principali

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.

3. Servizi esterni

Analytics, mappe, pagamenti e font usano più domini.

4. Iframe

frame-src non autorizza il provider.

5. Dati e blob

Immagini o worker richiedono schemi specifici.

6. Header duplicati

CDN, plugin e server applicano policy diverse.

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.

Fonti tecniche ufficiali

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

Domande frequenti

Guide Xlogic correlate

• Mixed content in WordPress dopo HTTPS: come risolverlo
• ERR_BLOCKED_BY_CSP: risorsa bloccata dalla Content Security Policy
• ModSecurity blocca WordPress: come diagnosticare il 403

Fonti tecniche

• WordPress Developer Resources