Perché Report-Only è diverso da Enforced in Content Security Policy

By Mirko Peters · 2026-04-23

Se ti occupi seriamente di sicurezza web, capire la differenza tra le modalità «report-only» ed «enforced» in Content Security Policy…

Automatically translated with AI from the original post. Read the English original

Se ti occupi seriamente di sicurezza web, capire la differenza tra le modalità «report-only» ed «enforced» in Content Security Policy (CSP) non è un dettaglio: è tutta la partita. La modalità report-only ti permette di vedere cosa verrebbe bloccato dalla tua policy senza bloccare realmente nulla, trasformando il tuo sito in una sorta di banco di prova per la sicurezza. La modalità enforced, invece, non scherza: blocca tutto ciò che va contro la policy, mettendo in sicurezza il sito in tempo reale.

Questo articolo analizza perché queste modalità sono importanti, quali effetti hanno sul browser e sull'esperienza utente e come passare dal semplice monitoraggio a una protezione reale. È pensato in particolare per i professionisti della sicurezza e gli sviluppatori che lavorano con Microsoft e vogliono configurare correttamente la CSP, con definizioni, tecniche pratiche e buone pratiche per un rollout sicuro e una compliance efficace.

Capire le modalità di CSP e il loro impatto

Prima di iniziare a distribuire header CSP, devi conoscere le due modalità principali di CSP: report-only ed enforced. Non sono semplici impostazioni: determinano il modo in cui i browser moderni proteggono (o si limitano a osservare) i confini di sicurezza della tua applicazione web. La scelta che fai incide direttamente sul livello di rischio del sito, sulla capacità di audit e sulla fluidità del rollout, soprattutto in grandi ambienti Microsoft o in configurazioni multi-cloud.

Le modalità CSP sono state pensate per offrire flessibilità ai team web. La modalità report-only è il punto di ingresso graduale: ti permette di monitorare eventuali problemi senza il timore di interrompere accidentalmente qualcosa per gli utenti. Supporta la valutazione del rischio, aiuta a individuare lacune nella policy e può far emergere codice legacy o comportamenti imprevisti di componenti di terze parti, mantenendo però l'applicazione pienamente operativa.

La modalità enforced è quella che conta davvero: dice al browser di applicare concretamente le tue istruzioni. Se un contenuto non rispetta la policy, viene bloccato immediatamente, riducendo la superficie di attacco per minacce come il cross-site scripting o gli script malevoli di terze parti. Ma significa anche che errori o policy incomplete possono interrompere l'applicazione, se non si presta attenzione ai test e all'adozione.

L'idea alla base delle due modalità è semplice: lasciare che sviluppatori e team di sicurezza affinino le regole sul campo prima di attivare il blocco. Pensala come le rotelle di sostegno per la sicurezza dell'applicazione, ma con un traguardo finale in cui si passa all'enforcement completo. Nel prossimo paragrafo vedremo esattamente come la modalità report-only fornisce questo riscontro reale e cosa cambia quando entra in gioco l'enforcement.

Come funziona Content-Security-Policy-Report-Only per la segnalazione delle violazioni

La modalità report-only è il modo in cui la CSP ti permette di osservare dalla tribuna prima di scendere in campo. Quando usi l'header HTTP Content-Security-Policy-Report-Only, dici al browser di «controllare le violazioni, ma non bloccare nulla, limitandosi a segnalarle». In questo modo ricevi un flusso di report sulle violazioni inviati all'endpoint che hai indicato, con un quadro completo di ciò che verrebbe bloccato se la policy fosse attiva.

I browser inviano questi report di violazione (spesso come payload JSON) ogni volta che una risorsa non rispetta le regole CSP. Ad esempio, se una pagina tenta di caricare uno script da una fonte non approvata, in modalità report-only nessuno script viene bloccato, ma ricevi comunque un avviso con i dettagli, come l'URL coinvolto, la direttiva violata e, talvolta, un campione del codice sospetto.

Questa modalità è preziosa per le valutazioni del rischio e per i test in sicurezza. Puoi distribuire nuove regole su un parco di applicazioni web, monitorare cosa viene attivato e ottimizzare la policy sulla base di dati reali, non di semplici supposizioni. Se gestisci sistemi legacy o flussi di lavoro business critici, non rischi interruzioni del sito o richieste di supporto andando troppo in fretta.

La modalità report-only supporta anche i rollout graduali. Parti con regole permissive, verifica cosa richiede un intervento e passa per gradi a una sicurezza più stringente. Permette di individuare problemi con script di terze parti, contenuti CDN o JavaScript offuscato che altrimenti resterebbero nascosti fino a quando l'enforcement non causa un guasto evidente. Inoltre è un vantaggio per la compliance: hai la prova di un monitoraggio attivo, utile durante gli audit quando l'organizzazione deve dimostrare la dovuta diligenza.

Come la modalità Enforced aumenta la sicurezza

La modalità imposta (enforced) è il punto in cui il tuo criterio CSP smette di essere un suggerimento e diventa una regola. Quando usi l'intestazione Content-Security-Policy, i browser bloccano davvero qualsiasi contenuto che non rispetti le tue direttive: niente avvisi, solo azione.

Questa modalità rende la tua web app molto più resistente ad attacchi come XSS e all'iniezione non autorizzata di script. Attenzione, però: se il tuo criterio non è ancora pronto per la produzione, potresti bloccare per errore risorse necessarie e compromettere il funzionamento del sito. La mossa giusta è testare prima in modalità solo report. In definitiva, la modalità imposta è ciò che trasforma un criterio teorico in una protezione concreta, rendendola lo standard di riferimento per una sicurezza web solida.

Implementare la segnalazione con gli endpoint report-uri e report-to

Configurare la segnalazione è ciò che dà al tuo criterio CSP un vero potere di controllo, oltre a una visibilità concreta. CSP ti permette di specificare uno o più endpoint (tramite report-uri o report-to) a cui i browser devono inviare i report di violazione. Quando si verifica una violazione, il browser raccoglie i dettagli, come la risorsa bloccata e il criterio non rispettato, li impacchetta in un messaggio JSON o HTTP POST e lo invia al tuo endpoint.

La direttiva report-uri è il metodo tradizionale: indichi un URL e i browser vi inviano direttamente i report. Per una gestione più moderna e reporting più completo, report-to è l'opzione più recente e robusta, soprattutto con il crescente supporto dei browser alla Reporting API. report-to funziona con un gruppo con nome, in grado di gestire diversi tipi di report, e offre un controllo del filtraggio più preciso.

Quando configuri questi endpoint, devono essere protetti: usa HTTPS, controlli di accesso e monitoraggio dei picchi anomali, che potrebbero indicare un attacco o un criterio non funzionante. Non dimenticare anche la privacy: i report possono contenere URL o persino frammenti di script incriminati, quindi devi essere pronto a ripulire le informazioni sensibili prima di archiviarle o condividerle, tenendo presenti normative come GDPR e CCPA.

Il vero vantaggio sta nella visibilità. Con una segnalazione configurata correttamente, ottieni un flusso in tempo reale di dove il tuo criterio intercetta le violazioni, così puoi intervenire, mettere a punto e passare con sicurezza alla modalità imposta senza sorprese. Questo livello di monitoraggio è essenziale, che tu gestisca una singola app o un ambiente Microsoft 365 complesso.

Orientarsi tra sintassi e direttive CSP per progettare criteri efficaci

Scrivere un'intestazione CSP solida non è una scienza missilistica, ma richiede attenzione ai dettagli, soprattutto quando si gestiscono app complesse e integrazioni con i servizi cloud Microsoft. Alla base, un criterio CSP è un elenco strutturato di direttive, ciascuna delle quali indica ai browser cosa è consentito e cosa no. Questi criteri si inviano tramite intestazioni HTTP, di solito come Content-Security-Policy o Content-Security-Policy-Report-Only, formattati come stringhe di regole separate da punto e virgola.

Il cuore del criterio è costituito da direttive chiave come default-src, script-src e img-src. default-src è il valore di ripiego: se un tipo specifico di contenuto non ha una regola propria, il browser controlla questa. script-src e img-src si concentrano rispettivamente su script e immagini, permettendoti di controllare con precisione le fonti attendibili (ad esempio i tuoi domini, CDN di fiducia e magari un blob di Microsoft Azure).

La sintassi conta. Ogni direttiva elenca i valori consentiti: URL, schemi come 'https:' o parole chiave come 'self'. Se consenti script inline (a volte necessario per codice legacy), potresti dover usare 'unsafe-inline', ma fai attenzione: questo indebolisce la protezione, a meno che non usi hash o nonce degli script per una validazione aggiuntiva.

Per chi lavora con Microsoft, presta attenzione a come i servizi cloud inseriscono le dipendenze. Le app aziendali complesse spesso caricano risorse dinamicamente, usano service worker o integrano provider di terze parti. Il tuo criterio deve bilanciare rigore, per la sicurezza, e flessibilità, per consentire il corretto funzionamento dell'app. Impostare bene le basi fin dall'inizio renderà i test molto più semplici in seguito.

Buone pratiche per passare dalla modalità solo report alla modalità imposta

La mossa più intelligente con CSP è iniziare in modalità solo report, raccogliere i dati e solo dopo attivare l'applicazione. Non trattare l'implementazione di CSP come una checklist da completare una volta per tutte. Approcciala piuttosto come un progetto a fasi, in cui monitori, metti a punto e irrigidisci gradualmente i criteri per evitare di compromettere le funzionalità per gli utenti finali o i flussi di lavoro business-critical.

Inizia con un criterio ampio ma sensato, in modalità di sola segnalazione. Raccogli le segnalazioni di violazione e, se possibile, aggregale con dashboard o strumenti di analisi per individuare i trasgressori ricorrenti. Così riduci il rumore, filtri i falsi positivi e ti concentri sui rischi reali. Se trovi molte segnalazioni di routine o ridondanti (cosa comune), affina le analisi dei log o aggiungi filtri in script basati su user agent o tipo di risorsa.

Quando i volumi delle violazioni calano e la maggior parte dei problemi è risolta, inizia ad applicare le regole gradualmente, continuando a monitorare l'eventuale comparsa di nuovi malfunzionamenti. Porta per primi in applicazione le sezioni ad alto rischio e basso traffico, e monitorale. Se tutto procede senza intoppi, estendi il criterio al resto del progetto. Documenta le modifiche e raccogli il feedback di sviluppatori e stakeholder lungo tutto il processo, soprattutto nelle app complesse di Microsoft 365 o Azure, dove i livelli di accesso condizionale aggiungono ulteriori complicazioni. Per strategie correlate e piani di rollout, vale la pena dare un'occhiata a questa guida sui problemi di fiducia dell'accesso condizionale e a questo episodio sulla sicurezza dell'identità.

Non sottovalutare mai i test. Usa gli strumenti di sviluppo del browser, i tester di stato CSP e perfino le scansioni automatiche in CI/CD per verificare che i criteri funzionino come previsto. L'obiettivo finale? Un'applicazione blindata, conforme e resiliente, protetta da un criterio che è stato affinato nel mondo reale e non basato su speranze.

Esempi reali di CSP in modalità di sola segnalazione e in modalità di applicazione

Niente rende CSP più concreto degli esempi pratici. In modalità di sola segnalazione potresti usare un header come: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Questa configurazione registra ogni violazione senza disturbare gli utenti, il che la rende perfetta per testare in produzione senza rischi.

Confronta questo con un criterio applicato: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Ora il browser blocca attivamente qualsiasi script o immagine che non rispetta le regole, proteggendo subito gli utenti da contenuti non approvati.

In pratica, le organizzazioni iniziano con la modalità di sola segnalazione per capire quali fornitori, script o funzionalità di business si bloccherebbero in un regime di blocco simulato. Per esempio, un portale web governativo potrebbe scoprire script legacy o una CDN di analytics di marketing che generano violazioni ripetute. Iterano, inseriscono in lista consentita i fornitori sicuri e poi applicano il criterio definitivo per fasi, così da ridurre al minimo le interruzioni.

Passare dalla sola segnalazione all'applicazione può far emergere mine nascoste, soprattutto con script di terze parti o contenuti dinamici. I team incontrano spesso violazioni «fantasma» che compaiono solo su alcuni browser o in condizioni specifiche. Usando i dati reali raccolti nella fase di sola segnalazione, regolano il criterio finché l'applicazione non è solo sicura, ma anche stabile per tutti gli interessati.

Riepilogo delle differenze principali tra modalità di sola segnalazione e modalità di applicazione

• Comportamento: La modalità di sola segnalazione si limita a segnalare le violazioni del criterio: nessun contenuto viene bloccato. La modalità di applicazione blocca attivamente tutto ciò che viola il tuo criterio CSP.
• Scopo: La modalità di sola segnalazione permette di testare e affinare i criteri senza alcun rischio per gli utenti. La modalità di applicazione serve alla protezione effettiva, rendendo operative le regole di sicurezza.
• Impatto sugli utenti: La modalità di sola segnalazione è invisibile: gli utenti non se ne accorgono. La modalità di applicazione può interrompere funzionalità o contenuti se le regole non sono state testate in anticipo.
• Casi d'uso: La modalità di sola segnalazione è ideale per rollout graduali, analisi dei rischi e verifiche di compatibilità con sistemi legacy. La modalità di applicazione è il passo finale per ottenere una sicurezza solida e conforme.
• Conformità e rischio: La modalità di sola segnalazione aiuta nel monitoraggio e nella documentazione durante gli audit, mentre la modalità di applicazione previene direttamente le violazioni di sicurezza in tempo reale.