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

By Mirko Peters · 2026-04-23

Se la sicurezza web ti sta a cuore, 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 la sicurezza web ti sta a cuore, 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 dal tuo criterio senza fermare 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 il tuo criterio, mettendo in sicurezza il sito in tempo reale.

Questo articolo spiega perché queste modalità sono importanti, quali effetti hanno sull'esperienza di browser e utenti e come passare dal semplice monitoraggio a una protezione reale. È pensato in particolare per i professionisti della sicurezza e per gli sviluppatori che lavorano su 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à CSP e il loro impatto

Prima di iniziare a distribuire header CSP, devi capire le due modalità principali: 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 dare flessibilità ai team web. La modalità report-only è il punto di partenza più morbido: ti consente di monitorare eventuali problemi senza il rischio di interrompere accidentalmente qualcosa per gli utenti. Supporta la valutazione dei rischi, aiuta a individuare lacune nel criterio e può far emergere codice legacy o comportamenti imprevisti di terze parti, mantenendo 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 il criterio, viene bloccato, riducendo immediatamente la superficie di attacco per minacce come il cross-site scripting o gli script malevoli di terze parti. Va però tenuto presente che errori o criteri incompleti possono interrompere l'applicazione se non si fanno test e adozione con attenzione.

L'idea alla base delle due modalità CSP è semplice: lasciare che sviluppatori e team di sicurezza perfezionino le regole sul campo prima di attivare il blocco. Pensala come le rotelle di sicurezza per la sicurezza della tua applicazione, ma con un traguardo in cui si passa alla piena applicazione. Nel prossimo passaggio vedremo esattamente come report-only fornisce questo feedback reale e cosa cambia quando entra in gioco la modalità enforced.

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

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

I browser inviano questi report di violazione (spesso come payload JSON) ogni volta che una risorsa non rispetta le regole della tua 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 incriminato, la direttiva violata e, a volte, un campione del codice sospetto.

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

Report-only supporta anche i rollout graduali. Parti in modo permissivo, verifica cosa va sistemato e procedi passo dopo passo verso una sicurezza più stringente. Permette ai team di scoprire problemi con script di terze parti, contenuti CDN o JavaScript offuscato che altrimenti resterebbero nascosti fino a quando l'enforcement non causa un guasto clamoroso. Inoltre è un vantaggio per la compliance: hai la prova che stai monitorando attivamente, il che può aiutare negli audit quando l'organizzazione deve dimostrare la dovuta diligenza.

Come la modalità enforced aumenta la sicurezza

La modalità enforced è il punto in cui il tuo criterio CSP smette di essere un semplice suggerimento e diventa una regola. Quando usi l'header Content-Security-Policy, i browser bloccano effettivamente qualsiasi contenuto che non rispetti le tue direttive: nessun avviso, solo azione.

Questa modalità rafforza in modo sostanziale la tua web app contro attacchi come XSS e l'iniezione non autorizzata di script. Attenzione però: se il tuo criterio non è ancora pronto, potresti bloccare per errore risorse necessarie e compromettere il funzionamento del sito. La mossa giusta è testare prima in modalità report-only. In definitiva, la modalità enforced è ciò che trasforma un criterio teorico in una protezione concreta, ed è lo standard di riferimento per una sicurezza web solida.

Implementare il reporting con gli endpoint Report-URI e Report-To

Configurare il reporting è ciò che dà al tuo criterio CSP un vero mordente, oltre a un paio d'occhi. CSP ti permette di specificare uno o più endpoint (usando report-uri oppure report-to) a cui i browser devono inviare i report di violazione. Quando si verifica una violazione, il browser raccoglie 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 legacy: indichi un URL e i browser vi inviano direttamente i report. Per una maggiore flessibilità moderna e un reporting più ricco, report-to è l'opzione più recente e robusta, soprattutto con l'espansione del supporto alla Reporting API nei browser. report-to lavora con un gruppo con nome, in grado di gestire diversi tipi di report, e offre un controllo di filtraggio migliore.

Quando configuri questi endpoint, devono essere protetti: HTTPS, controlli di accesso e monitoraggio di picchi inattesi (che potrebbero indicare un attacco o un criterio difettoso). Non dimenticare inoltre la privacy: i report possono contenere URL o persino frammenti dello script incriminato, quindi devi essere pronto a ripulire le informazioni sensibili prima di archiviarle o condividerle, tenendo presenti normative come GDPR e CCPA.

Il vero punto di forza è la visibilità. Con un reporting configurato correttamente ottieni un flusso in tempo reale di dove il tuo criterio intercetta le violazioni, così puoi regolare, mettere a punto e passare con sicurezza alla modalità enforcement senza sorprese. Questo livello di monitoraggio è essenziale, sia che tu gestisca una singola app sia che tu presidi un ambiente Microsoft 365 esteso.

Navigare nella sintassi e nelle direttive CSP per progettare un criterio efficace

Scrivere un header CSP solido 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, ognuna delle quali indica al browser cosa è consentito e cosa no. Questi criteri si inviano tramite header HTTP, di norma come Content-Security-Policy o Content-Security-Policy-Report-Only, formattati come stringhe di regole separate da punto e virgola.

Il cuore del criterio sta in 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 consulta questa. script-src e img-src si concentrano su script e immagini, permettendoti di controllare con precisione le fonti attendibili (pensa ai tuoi domini, ai CDN fidati e magari a un blob di 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 necessari per codice legacy), potresti dover usare 'unsafe-inline', ma attenzione: questo indebolisce la protezione, a meno che tu 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 proprie dipendenze. Le app aziendali complesse caricano spesso asset dinamicamente, usano service worker o integrano provider di terze parti. Il tuo criterio deve bilanciare rigore (per la sicurezza) e flessibilità sufficiente a far funzionare l'app. Impostare bene le basi fin dall'inizio renderà i test molto più fluidi in seguito.

Best practice per passare dalla modalità report-only alla modalità enforced

La mossa più intelligente con CSP è partire dalla modalità report-only, raccogliere i dati e solo dopo attivare l'enforcement. 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 la funzionalità per gli utenti finali o per i flussi di lavoro critici per il business.

Inizia con un criterio ampio ma ragionevole, in modalità solo report. Raccogli le segnalazioni di violazione, idealmente aggregandole con dashboard o strumenti di analisi per evidenziare i responsabili ricorrenti. Così riesci a separare il rumore dai falsi positivi e a concentrarti sui rischi reali. Se trovi molte segnalazioni di routine o ridondanti (cosa comune), ottimizza l'analisi dei log o applica filtri a script in base allo user agent o al tipo di risorsa.

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

Non sottovalutare mai i test. Usa gli strumenti di sviluppo del browser, i tester di stato CSP e persino 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 affinato nel mondo reale e non da buone intenzioni.

Esempi reali di CSP in modalità solo report e applicata

Niente rende concreta la CSP come gli esempi pratici. In modalità solo report, 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, ed è quindi perfetta per testare in produzione senza rischi.

Al contrario, 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 ogni script o immagine che non rispetta le regole, proteggendo subito gli utenti dai contenuti non approvati.

In pratica, le organizzazioni iniziano con la modalità solo report per capire quali fornitori, script o funzioni di business si romperebbero con un blocco rigoroso. Ad esempio, un portale web governativo potrebbe scoprire script legacy o una CDN di analytics di marketing che genera violazioni ripetute. Procedono per iterazioni, inseriscono in lista consentita i fornitori sicuri e poi applicano il criterio definitivo per fasi, così da ridurre al minimo le interruzioni.

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

Riepilogo delle differenze principali tra modalità solo report e applicata

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