Come proteggere WordPress con il Content Security Policy (CSP)
Il Content Security Policy (CSP) è un header di sicurezza HTTP che protegge il tuo sito WordPress da attacchi come Cross-Site Scripting (XSS), clickjacking e data injection. Definisce quali risorse (script, stili, immagini, font) possono essere caricate nel browser dei visitatori e da quali origini. In questa guida ti spiego come funziona il CSP e come implementarlo su WordPress senza rompere il sito.
Come funziona il Content Security Policy
Quando un browser carica una pagina del tuo sito, il CSP gli dice esattamente da dove può caricare le risorse. Se uno script malevolo viene iniettato nella pagina (ad esempio tramite un attacco XSS), il browser lo blocca perché non proviene da un’origine autorizzata.
Il CSP viene inviato come header HTTP nella risposta del server:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.esempio.com;
Questa policy dice al browser: “Carica le risorse solo dal dominio del sito (‘self’) e gli script anche da cdn.esempio.com. Blocca tutto il resto.”
Le direttive principali del CSP
Il CSP si compone di diverse direttive, ognuna che controlla un tipo di risorsa:
- default-src: fallback per tutte le risorse non specificate da altre direttive.
- script-src: origini autorizzate per i file JavaScript. La più importante per prevenire XSS.
- style-src: origini autorizzate per i fogli di stile CSS.
- img-src: origini autorizzate per le immagini.
- font-src: origini autorizzate per i web font.
- connect-src: origini autorizzate per le connessioni AJAX, WebSocket e fetch.
- frame-src: origini autorizzate per iframe e embed.
- media-src: origini autorizzate per audio e video.
- object-src: controlla plugin come Flash. Imposta sempre ‘none’.
I valori comuni sono: ‘self’ (stesso dominio), ‘none’ (blocca tutto), ‘unsafe-inline’ (permette stili e script inline), URL specifici dei CDN e servizi esterni.
Perché il CSP è complicato su WordPress
WordPress, i temi e molti plugin usano ampiamente stili e script inline e funzioni come wp_add_inline_style() e wp_add_inline_script(). Questo rende difficile creare un CSP restrittivo perché dovresti usare ‘unsafe-inline’ per non rompere il sito.
Inoltre, WordPress carica risorse da diverse origini:
- Google Fonts (fonts.googleapis.com e fonts.gstatic.com)
- Google Analytics / Tag Manager (googletagmanager.com, google-analytics.com)
- CDN (cdnjs.cloudflare.com, cdn.jsdelivr.net)
- Servizi embed (youtube.com, vimeo.com, twitter.com)
- Gravatar (secure.gravatar.com)
Ogni servizio esterno deve essere esplicitamente autorizzato nel CSP.
Implementare il CSP gradualmente
Non implementare un CSP restrittivo tutto in una volta: romperesti quasi certamente qualcosa. Segui questo approccio graduale:
Fase 1: modalità Report-Only
Inizia con l’header Content-Security-Policy-Report-Only invece di Content-Security-Policy. In questa modalità, il browser segnala le violazioni nella console del browser senza bloccare nulla. Puoi così vedere cosa verrebbe bloccato senza impattare i visitatori.
Fase 2: analizzare le violazioni
Apri la console del browser (F12 → Console) e naviga il sito. Ogni violazione CSP viene segnalata con un messaggio che indica la direttiva violata e la risorsa bloccata. Annota tutte le origini che devono essere autorizzate.
Fase 3: costruire la policy definitiva
Dopo aver raccolto tutte le origini necessarie, costruisci la policy definitiva e passa da Report-Only a Content-Security-Policy per attivare il blocco effettivo.
Come aggiungere il CSP a WordPress
Puoi aggiungere il CSP in tre modi:
Via functions.php o plugin:
add_action('send_headers', function() {
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https://secure.gravatar.com;");
});
Via .htaccess (Apache):
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';"
Via configurazione Nginx:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';";
In alternativa, il plugin HTTP Headers o Really Simple Security (ex SSL) offrono un’interfaccia grafica per configurare il CSP senza toccare codice.
Un CSP di partenza per WordPress
Ecco un esempio di CSP ragionevole per un sito WordPress standard con Google Analytics, Google Fonts, YouTube embed e Gravatar:
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://secure.gravatar.com https://www.google-analytics.com; font-src 'self' https://fonts.gstatic.com; frame-src https://www.youtube.com https://www.google.com; connect-src 'self' https://www.google-analytics.com; object-src 'none'; base-uri 'self'; form-action 'self';
Importante: questo è un punto di partenza. Ogni sito è diverso e il CSP va personalizzato in base ai servizi e ai plugin che utilizzi.
Testare e monitorare il CSP
Dopo aver implementato il CSP:
- Testa tutte le pagine: homepage, articoli, pagine, form di contatto, carrello WooCommerce (se presente).
- Controlla la console del browser: eventuali risorse bloccate verranno segnalate come errori.
- Usa strumenti online: siti come securityheaders.com e il CSP Evaluator di Google ti aiutano a verificare la correttezza della policy.
- Monitora nel tempo: quando aggiungi nuovi plugin o servizi, potresti dover aggiornare il CSP per autorizzare nuove origini.
Serve assistenza?
Implementare un Content Security Policy efficace su WordPress richiede competenza tecnica e test approfonditi. Se vuoi proteggere il tuo sito dagli attacchi XSS senza rompere funzionalità, il team di SoccorsoWP può configurare il CSP perfetto per il tuo sito. Apri un ticket e rafforza la sicurezza del tuo WordPress.
