La Content Security Policy (CSP) è una delle principali tecniche di sicurezza che i webmaster e i developer possono utilizzare per proteggere un sito web da attacchi come Cross-Site Scripting (XSS), clickjacking e altre vulnerabilità connesse all’iniezione di contenuti malevoli. Tuttavia, nel contesto attuale di un web sempre più data-driven, è fondamentale che la CSP sia configurata in modo da non ostacolare strumenti legittimi di tracciamento, marketing e analytics, come Google Tag Manager (GTM), Google Analytics 4 (GA4), Google Consent Mode V2, e le principali piattaforme pubblicitarie (es. Google Ads, Meta Ads).
In questo articolo approfondiremo tutti gli aspetti tecnici del problema, fornendo indicazioni precise per:
Capire come funziona la CSP
Diagnosticare errori e incompatibilità con GTM, GA4 e la CMP
Correggere la configurazione per non bloccare il tracciamento
Garantire la conformità al GDPR senza compromettere la raccolta dati
Cos'è la Content Security Policy e perché è importante
Analizziamo ora in dettaglio questo aspetto che è, per sua natura, molto tecnico.
Che cos'è la CSP
La Content Security Policy è un header HTTP che definisce le fonti da cui una pagina web è autorizzata a caricare contenuti (script, immagini, iframe, fogli di stile, ecc.). In particolare, la direttiva connect-src specifica da quali origini possono essere effettuate connessioni di rete (es. fetch, XMLHttpRequest, WebSocket, sendBeacon).
Esempio di CSP restrittiva
Content-Security-Policy: connect-src ‘self’;
Questa configurazione consente connessioni solo verso il dominio corrente e blocca tutto il resto.
Perché una CSP troppo chiusa crea problemi
Se non vengono inclusi domini esterni utilizzati da strumenti di analytics o advertising:
Le richieste a Google Analytics o server GTM vengono bloccate
Il browser impedisce la comunicazione con il contenitore server-side
Il tracciamento lato client e server non funziona
Le CMP non riescono a notificare lo stato del consenso
Effetti della CSP su Google Tag Manager e strumenti di analytics
Gli effetti generati da una policy troppo restrittiva potrebbero anche non rivelarsi subito. Può succedere di “incappare” in uno di questi problemi quasi per caso.
Google Tag Manager server-side e GA4
Quando utilizzi GTM in modalità server-side, i dati degli utenti non vengono inviati direttamente a Google Analytics, ma transitano da un endpoint intermedio (contenitore server) configurato su un sottodominio, ad esempio:
https://sst.dominio.it/g/collect
Il parametro server_container_url forza il browser a inviare gli eventi GA4 verso questo dominio. Se non è incluso nella CSP, la richiesta viene bloccata e i dati non arrivano mai al contenitore server.
Effetti concreti:
Nessun evento visualizzabile in modalità preview del contenitore server
Apparente corretto funzionamento del tag GA4 nel contenitore web, ma nessuna trasmissione di dati
Google Consent Mode V2 e la chiamata ccm/collect
Dal 2024, con l’introduzione obbligatoria della Google Consent Mode V2, GTM effettua una chiamata di rete a:
https://www.google.com/ccm/collect
Questa è utilizzata per sincronizzare lo stato del consenso utente tra la CMP e Google. Se la chiamata è bloccata dalla CSP:
Lo stato di consenso non viene trasmesso
I tag GTM rispettano la modalità “denied” anche se l’utente ha acconsentito
GA4 e Google Ads non ricevono alcun dato
Google Ads e Meta Pixel
Se usi strumenti pubblicitari come:
Google Ads: richieste a
https://googleads.g.doubleclick.netMeta Ads: richieste a
https://www.facebook.com,https://connect.facebook.net
Una CSP troppo chiusa blocca i beacon di conversione, disabilitando completamente il remarketing e l’attribuzione pubblicitaria.
Come identificare i problemi causati dalla CSP
Console errori nel browser
Vai su DevTools > Console e cerca messaggi come:
Content Security Policy: The page’s settings blocked the connection to …
Oppure:
Refused to connect to ‘https://www.google.com/ccm/collect’ because it violates the Content Security Policy directive: connect-src ‘self’
Network tab
Nel tab Network > filtrando per “collect”, verifica:
Se ci sono chiamate a
/g/collectverso il tuo dominio server-sideSe
ccm/collectrestituisce errore o è assenteSe
googleads.g.doubleclick.netoconnect.facebook.netrisultano bloccati
Modalità preview GTM server
Se hai impostato correttamente server_container_url, ma nel contenitore server-side non appare alcun evento, è molto probabile che la richiesta venga bloccata lato browser dalla CSP.
Come risolvere: configurare una CSP compatibile con GTM e tracciamenti
Dopo aver analizzato cosa sono le policy CSP e quali problemi può generare una errata configurazione, vediamo ora come è possibile risolverli.
Direttiva connect-src aggiornata
Il modo più rapido ma che consente di mantenere un ottimo livello di sicurezza, è quello di introdurre nella direttiva di configurazione tutti i domini a cui il browser deve potersi connettere.
Per esempio:
Content-Security-Policy: connect-src ‘self’ https://www.google.com https://www.googletagmanager.com https://www.google-analytics.com https://sst.dominio.it https://googleads.g.doubleclick.net https://www.facebook.com https://connect.facebook.net;
Spiegazione dei domini
Vediamo ora una spiegazione ed indicazione di quali domini sarà quasi certamente necessario tenere conto nella riconfigurazione delle politiche CSP.
Ho indicato in coda alla tabella le principali CMP, ovviamente sarà necessario inserire una policy solo per quella effettivamente in uso.
| Dominio | Utilizzo |
|---|---|
|
https://www.google.com |
Consent Mode V2 |
|
https://www.googletagmanager.com |
GTM Web |
|
https://www.google-analytics.com |
GA4 fallback |
|
https://sst.dominio.it |
Endpoint contenitore server-side |
|
https://googleads.g.doubleclick.net |
Conversioni Google Ads |
|
https://www.facebook.com |
Meta Pixel |
|
https://connect.facebook.net |
Libreria JS Meta |
|
https://consent.cookiebot.com |
CMP Cookiebot |
|
https://policy.app.cookieinformation.com |
Script policy Cookiebot |
|
https://cdn.iubenda.com |
CMP Iubenda |
|
https://privacyportal-de.onetrust.com |
CMP Complianz/OneTrust |
|
https://cmp.quantcast.com |
CMP alternative (Quantcast) |
Implementazione tramite .htaccess
Se il sito gira su Apache (tipico di WordPress), apri il file .htaccess e inserisci prima del blocco # BEGIN WordPress:
<IfModule mod_headers.c>
Header set Content-Security-Policy “default-src ‘self’; connect-src ‘self’ https://www.google.com https://www.googletagmanager.com https://www.google-analytics.com https://sst.dominio.it https://googleads.g.doubleclick.net https://www.facebook.com https://connect.facebook.net;”
</IfModule>
Altri metodi di implementazione
Plugin WordPress: WP CSP Plugin, iThemes Security
Cloudflare: se usi proxy/reverse proxy, imposta CSP a livello WAF
Header lato codice PHP: solo se il server è custom e gestito manualmente
Test e report sullo stato della Content Security Policy
Per poter verificare lo stato della Content Security Policy esistono, per fortuna, diversi strumenti disponibili online.
Il mio preferito è Security Headers, ma puoi utilizzare i tool seguenti che forniscono buone indicazioni:
Conclusioni
Una Content Security Policy è fondamentale per proteggere un sito web, ma deve essere bilanciata con le esigenze del digital marketing moderno.
Bloccando domini utilizzati da strumenti di tracciamento e gestione del consenso, si rischia:
Di invalidare il tracciamento server-side
Di non rispettare il consenso GDPR
Di perdere dati e conversioni
La soluzione è una CSP intelligente e calibrata, che protegge il sito ma consente i flussi verso le piattaforme legittime.
Se usi GTM, GA4, server-side tagging, Google Ads o Meta Ads, è cruciale includere le fonti elencate in connect-src.
Una CSP ben progettata è sinonimo di sicurezza e performance allo stesso tempo.
FAQ
Una CSP è un header HTTP che indica al browser quali fonti di contenuti sono autorizzate per un sito web. In pratica dice al browser da quali domini può caricare script, immagini, stili, iframe e altre risorse, creando uno strato di sicurezza contro contenuti potenzialmente malevoli.
Perché aiuta a mitigare attacchi come il cross-site scripting (XSS) e altre iniezioni di codice indesiderato, riducendo il rischio che un contenuto esterno o malevolo venga eseguito nel contesto del tuo dominio.
No. La CSP non sostituisce la validazione, la sanitizzazione degli input o altre buone pratiche di sicurezza. Funziona meglio come parte di una difesa multilivello, non come unico strumento di protezione.
Sì — e questo è un rischio reale nel contesto di tracciamento e marketing analitico. Se una CSP blocca richieste verso domini legittimi (per esempio per GTM, GA4, server-side tagging o CMP), strumenti essenziali non funzioneranno correttamente.
Gli strumenti di debug dei browser (Console degli strumenti di sviluppo, Network tab) mostrano messaggi quando una risorsa viene bloccata dalla CSP, ad esempio: Refused to connect to … because it violates the Content Security Policy directive.
Se la policy non include i domini usati da strumenti di tracciamento (es. Google Analytics, Google Ads, Meta Pixel o endpoint server-side), sì: il browser bloccherà quelle richieste, interrompendo il tracciamento.
Inserendo nella policy solo i domini necessari per GTM, GA4, CMP e altri servizi di cui hai bisogno — ad esempio aggiornando la direttiva connect-src con le origini legittime. È un equilibrio tra sicurezza e funzionalità.
La forma consigliata è tramite header HTTP (Content-Security-Policy), perché permette un controllo più consistente e può funzionare in tutti i contesti di risposta server. Inviare la policy usando solo un tag meta ha limitazioni ed è meno efficace.
Sì. La maggior parte dei browser moderni interpreta e applica le regole CSP quando l’header è presente, e ignora specifiche non supportate senza interrompere il sito.
Esistono strumenti online specifici per analizzare e valutare le intestazioni di sicurezza, compresa la CSP, per capire se ci sono blocchi indesiderati o vulnerabilità.