Come configurare una Content-Security-Policy in WordPress

Content-Security-Policy (CSP) è uno degli header di sicurezza più potenti disponibili, ma è anche uno dei più difficili da configurare correttamente su WordPress. Il motivo è semplice: il core di WordPress, i temi e i plugin amano fare uso di script e stili inline. Una CSP rigorosa li blocca per default, il che significa che il tuo sito può rompersi in modi inaspettati se non pianifichi con attenzione. Questa guida ti accompagna attraverso l'intero processo, dalla comprensione di cosa fa CSP al deployment di una policy pronta per la produzione.

Perché CSP è particolarmente impegnativo su WordPress

La maggior parte dei siti WordPress fa molto affidamento sui pattern che CSP intende limitare. Ecco i problemi più comuni che incontrerai:

• Script inline: molti plugin iniettano JavaScript direttamente nell'HTML tramite tag <script> senza attributo src. Page builder come Elementor, WPBakery e Divi lo fanno ampiamente.
• Stili inline: il Customizer WordPress, i blocchi Gutenberg e la maggior parte dei temi aggiungono attributi style o blocchi <style> alla pagina. Una CSP rigorosa senza 'unsafe-inline' per gli stili rompe l'aspetto visivo del tuo sito.
• Uso di eval(): alcuni plugin usano la funzione eval() di JavaScript o costrutti simili, per cui è necessaria la direttiva 'unsafe-eval'.
• Risorse esterne: Google Analytics, Google Fonts, reCAPTCHA, video YouTube incorporati, widget social. Per ognuno serve una voce CSP propria.

A causa di tutto questo, non dovresti mai copiare una CSP da un altro sito web e incollarla nella tua configurazione WordPress. Ogni sito WordPress ha una combinazione unica di plugin e tema, quindi ogni CSP deve essere fatta su misura.

Inizia in modalità report-only per scoprire cosa si romperebbe

Il modo più sicuro per iniziare è con l'header Content-Security-Policy-Report-Only. Questo header si comporta esattamente come CSP, tranne che non blocca effettivamente nulla. Invece, le violazioni vengono registrate nella console del browser, in modo che tu possa vedere cosa la tua policy fermerebbe. Niente sul tuo sito si rompe, ma ottieni una visibilità completa.

Aggiungi questo al tuo file .htaccess (Apache):

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';"
</IfModule>

O per Nginx:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';" always;

Lascialo funzionare per almeno alcuni giorni e naviga tutte le pagine importanti del tuo sito (home, articoli del blog, modulo di contatto, checkout WooCommerce se applicabile). Ogni pagina può caricare plugin e risorse diverse.

Come trovare le violazioni CSP nella console del browser

Dopo aver abilitato la modalità Report-Only, apri il tuo sito in Chrome o Firefox e premi F12 per aprire i DevTools. Vai alla scheda Console. Le violazioni CSP appaiono come messaggi di avviso che hanno questo aspetto:

[Report Only] Refused to load the script 'https://www.googletagmanager.com/gtag/js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'".

Ogni messaggio di violazione ti dice esattamente cosa è stato bloccato e quale direttiva l'ha causato. Raccogli tutti questi messaggi e usali per costruire la tua allowlist. Visita ogni pagina importante sul tuo sito, incluse pagine con moduli, slider, mappe e pagine che caricano plugin unici.

Comprendere le principali direttive CSP per WordPress

Ecco le direttive che probabilmente devi configurare:

• default-src: il fallback per tutti i tipi di risorse non elencati esplicitamente. Imposta questo a 'self' come baseline.
• script-src: controlla da dove può essere caricato JavaScript. Su WordPress hai quasi certamente bisogno di 'unsafe-inline'. Se un plugin usa eval(), hai bisogno anche di 'unsafe-eval'.
• style-src: controlla da dove possono essere caricati i CSS. WordPress richiede qui quasi sempre 'unsafe-inline'.
• img-src: controlla le fonti delle immagini. Usa 'self' data: https: per consentire le tue immagini, URI di dati (usati da molti plugin) e qualsiasi immagine tramite HTTPS.
• font-src: controlla il caricamento dei font. Se usi Google Fonts, aggiungi https://fonts.gstatic.com.
• connect-src: controlla dove JavaScript può fare richieste di rete (AJAX, fetch, WebSocket). L'area di amministrazione di WordPress usa questo pesantemente per la REST API e l'Heartbeat API.
• frame-src: controlla quali domini possono essere caricati in iframe. Necessario per gli embed YouTube (https://www.youtube.com), Google Maps (https://www.google.com) e reCAPTCHA (https://www.google.com).
• media-src: controlla le fonti audio e video. Tipicamente 'self' è sufficiente, a meno che tu non incorpori media esterni.
• object-src: controlla plugin come Flash. Imposta a 'none' dato che Flash è morto e questa direttiva difende principalmente da vettori di attacco più vecchi.

Costruire la tua policy passo dopo passo

Inizia con una baseline restrittiva e aggiungi eccezioni mentre scopri violazioni:

1. Inizia con una policy minima: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. Aggiungi unsafe-inline per script e stili: questo è quasi sempre necessario su WordPress. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. Aggiungi URI data: per immagini e font: molti plugin usano immagini codificate in base64. img-src 'self' data: https:; font-src 'self' data:;
4. Metti in whitelist il tuo CDN: se usi un CDN come Cloudflare o BunnyCDN, aggiungi il dominio a script-src, style-src, img-src e font-src.
5. Aggiungi servizi esterni uno alla volta: per ogni violazione CSP nella console, aggiungi il dominio specifico alla direttiva corrispondente.

Voci di allowlist comuni per siti WordPress

Ecco una panoramica dei domini di cui potresti aver bisogno per le integrazioni WordPress popolari:

• Google Fonts: style-src https://fonts.googleapis.com e font-src https://fonts.gstatic.com
• Google Analytics / GA4: script-src https://www.googletagmanager.com https://www.google-analytics.com e connect-src https://www.google-analytics.com https://analytics.google.com
• Google Maps: script-src https://maps.googleapis.com e frame-src https://www.google.com
• Embed YouTube: frame-src https://www.youtube.com https://www.youtube-nocookie.com
• reCAPTCHA: script-src https://www.google.com https://www.gstatic.com e frame-src https://www.google.com
• Gravatar: img-src https://secure.gravatar.com https://www.gravatar.com
• WordPress.org: img-src https://s.w.org https://ps.w.org (per icone plugin/tema nell'area di amministrazione)

Un esempio CSP WordPress completo

Ecco una CSP realistica per un sito WordPress che usa Google Analytics, Google Fonts, embed YouTube e Gravatar. Adattala alle tue esigenze specifiche:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: https://secure.gravatar.com; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https://www.google-analytics.com https://analytics.google.com; frame-src https://www.youtube.com https://www.youtube-nocookie.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

Plugin WordPress per gestire CSP

Se la modifica dei file di configurazione del server sembra scoraggiante, questi plugin possono aiutare:

• HTTP Headers: un plugin gratuito con cui puoi definire tutti gli header di sicurezza dall'area di amministrazione WordPress. Supporta CSP con un'interfaccia user-friendly dove puoi aggiungere sorgenti per direttiva.
• Really Simple SSL Pro: include un modulo Content-Security-Policy con log di violazione e soluzioni con un click per problemi comuni.
• Il plugin CSP di Jeremykendall: un'opzione leggera focalizzata esclusivamente sulla gestione CSP.

Tieni presente che gli header CSP basati su plugin vengono inviati solo per le pagine elaborate da WordPress. Le risorse statiche servite direttamente dal tuo web server non portano l'header. Per una protezione completa, la configurazione a livello di server è preferibile.

Passare da Report-Only alla modalità di enforcement

Se hai eseguito in modalità Report-Only per almeno una settimana e risolto tutte le violazioni, sei pronto a passare. Semplicemente cambia il nome dell'header da Content-Security-Policy-Report-Only a Content-Security-Policy. Tieni la console del browser aperta nelle prime ore e monitora le violazioni che potresti aver perso. Se qualcosa si rompe, puoi sempre tornare a Report-Only mentre lo risolvi.

Verifica la tua CSP con InspectWP

Dopo aver implementato la tua Content-Security-Policy, esegui una nuova scansione InspectWP. La sezione header di sicurezza nel tuo report mostra se è presente un header CSP e se è in modalità Report-Only o di enforcement. Usalo come controllo rapido dopo ogni modifica per confermare che la tua policy continua a essere inviata correttamente.