Due strumenti in uno. Il builder compone un header Content-Security-Policy scegliendo le direttive principali (default-src, script-src, frame-ancestors e altre) con valori canonici come 'self', 'none', nonce e 'strict-dynamic'. Il validatore analizza una CSP che incolli e ti segnala le debolezze che vanificano la protezione: 'unsafe-inline', wildcard *, data: in script-src, assenza di default-src o frame-ancestors. Tutto client-side: nessun dato lascia il tuo browser.
Scegli il valore di ogni direttiva. La baseline preimpostata è già una policy sicura ('self' ovunque, frame-ancestors 'none'): parti da qui e allenta solo dove serve.
Incolla una Content-Security-Policy esistente (anche l'header completo). Il report delle debolezze si aggiorna mentre digiti, senza premere alcun pulsante.
Ogni direttiva ha un menu a tendina con i valori canonici. La configurazione iniziale è già una baseline sicura: default-src 'self', script e style dalla sola origine, frame-ancestors 'none' contro il clickjacking. Restringi con 'none' ciò che non ti serve, allenta solo dove l'applicazione lo richiede davvero.
Nel campo host aggiuntivi elenca i domini di terze parti legittimi (il CDN degli script, l'endpoint delle API). Attiva upgrade-insecure-requests se hai risorse http:// residue, e imposta report-uri per raccogliere le violazioni. La modalità report-only genera l'header di collaudo che osserva senza bloccare.
Il pulsante Genera produce l'header Content-Security-Policy completo, pronto da incollare nella configurazione di Apache, Nginx o del middleware applicativo. Copia con un click. Se hai scelto un valore con nonce, sostituisci {NONCE} con il token casuale che il tuo server genera a ogni request.
Incolla nel validatore la CSP che stai già servendo (o l'header intero copiato da curl -I). Il report evidenzia in tempo reale ciò che indebolisce la protezione, assegna una severità a ogni finding e calcola un punteggio di hardening indicativo. Correggi nel builder e rigenera.
Cosa fa davvero. La Content-Security-Policy è un header HTTP di risposta che dice al browser da quali origini può caricare ed eseguire risorse: script, stili, immagini, font, frame, connessioni di rete. È una allowlist dichiarativa. Con script-src 'self' il browser esegue solo il JavaScript servito dal tuo dominio e rifiuta tutto il resto, compreso il payload che un attaccante riesce a iniettare tramite un cross-site scripting. La CSP non ripara la vulnerabilità di injection a monte, ma neutralizza la fase di sfruttamento: lo script iniettato semplicemente non parte. È difesa in profondità che costa zero performance e si attiva con una riga di configurazione.
La trappola di 'unsafe-inline'. Il modello di sicurezza della CSP si regge su una distinzione: il codice che arriva da una sorgente fidata gira, quello inline (dentro <script> o negli attributi onclick=) no, perché il browser non può distinguere l'inline legittimo da quello iniettato. Aggiungere 'unsafe-inline' a script-src riapre esattamente la porta che la CSP doveva chiudere: qualunque payload iniettato torna eseguibile e la protezione XSS si azzera. Le alternative moderne sono tre: un nonce casuale per request marcato sui soli script legittimi, un hash SHA-256 del contenuto inline atteso, oppure 'strict-dynamic' che propaga la fiducia dagli script con nonce a quelli che caricano dinamicamente, liberandoti dal mantenere una lista di host.
Builder e validatore, un flusso solo. Il builder parte da una baseline volutamente restrittiva perché nella CSP la sicurezza è il default e l'apertura è l'eccezione da giustificare. Comporre la policy scegliendo i valori evita gli errori di sintassi (un punto e virgola di troppo, una direttiva scritta male) che rendono la CSP silenziosamente inefficace. Il validatore chiude il cerchio sull'esistente: incolli la policy che già servi e vedi subito se un *, un data: in script-src o l'assenza di default-src stanno lasciando una falla. Nessuno dei due strumenti contatta la rete.
Report-only prima di enforce. Applicare una CSP stretta a un sito vivo senza collaudo rompe risorse legittime. Per questo esiste Content-Security-Policy-Report-Only: la policy viene valutata e ogni violazione è registrata e inviata al tuo report-uri, ma nulla viene bloccato. Si osserva per giorni o settimane il traffico reale, si raffina la policy sui report, e solo quando i falsi positivi sono a zero si passa all'header che blocca. Privacy per costruzione: builder e validatore girano interamente nel browser, il sito che stai proteggendo non viene mai contattato dai nostri server, quindi puoi lavorare anche su ambienti di staging e intranet non esposti.
| Direttiva | A cosa serve | Valore tipico consigliato |
|---|---|---|
| default-src | Fallback per tutte le direttive di fetch non dichiarate esplicitamente. Il perno di ogni policy. | 'self' |
| script-src | Da dove il browser può caricare ed eseguire JavaScript. La direttiva decisiva per l'XSS. | 'self' oppure 'self' 'nonce-...' |
| style-src | Sorgenti dei fogli di stile e degli stili inline. | 'self' |
| img-src | Sorgenti delle immagini; data: per le immagini inline base64. | 'self' data: |
| connect-src | Endpoint raggiungibili via fetch, XHR, WebSocket, EventSource, sendBeacon. | 'self' |
| font-src | Sorgenti dei web font. | 'self' |
| frame-src | Sorgenti che la tua pagina può caricare come frame o iframe. | 'self' o 'none' |
| frame-ancestors | Chi può includere la tua pagina in un frame. Erede moderno di X-Frame-Options. | 'none' |
| base-uri | Limita l'URL del tag base, evitando che un'injection dirotti i path relativi. | 'self' |
| form-action | Destinazioni consentite per l'attributo action dei form. | 'self' |
Termini tecnici usati in questa pagina, spiegati in due righe.
nome-direttiva sorgenti (es. script-src 'self'). Le direttive sono separate da punto e virgola all'interno dell'header. 'self', 'none'), schemi (https:, data:), host (https://cdn.example.com) e wildcard. 'nonce-...' e come attributo nonce sui soli script legittimi. Rende sicuro l'inline senza allowlist di host. 'sha256-...'. Il browser esegue l'inline solo se il suo hash combacia. Alternativa statica al nonce. <frame> o <iframe>. Con 'none' è la difesa contro il clickjacking, più espressiva di X-Frame-Options. report-uri è la forma storica ancora supportata; report-to è il successore moderno basato sul Reporting API. Essenziali per collaudare in report-only. script-src stretta quel codice non viene eseguito dal browser.Content-Security-Policy applica la policy: le risorse fuori dalla allowlist vengono bloccate davvero. L'header Content-Security-Policy-Report-Only valuta la stessa policy ma non blocca nulla: registra soltanto le violazioni e le invia al report-uri. Report-only è il modo corretto di collaudare una CSP su un sito in produzione prima di attivarla, così da scoprire i falsi positivi senza rompere l'esperienza degli utenti.script-src 'nonce-r4nd0m' e come attributo sui tag che vuoi autorizzare: <script nonce="r4nd0m">. Il browser esegue solo gli inline che portano il nonce corrente. Poiché l'attaccante non può prevedere il valore, il suo script iniettato non lo avrà e resterà bloccato. È l'alternativa sicura a 'unsafe-inline'.script-src vanifica la protezione. La CSP funziona proprio perché distingue il codice fidato dall'inline arbitrario; 'unsafe-inline' dice al browser di eseguire qualunque script inline, compreso quello iniettato da un XSS. In pratica riporti la pagina allo stato di partenza. Se hai molti onclick= legacy, migra gradualmente a nonce, hash oppure ad addEventListener in JavaScript esterno, invece di lasciare la direttiva aperta.frame-ancestors 'none' nella CSP: nessuna pagina, di nessuna origine, potrà incorporare la tua in un frame o iframe. Se vuoi consentire solo la tua stessa origine, usa frame-ancestors 'self'. Questa direttiva è più espressiva e affidabile del vecchio header X-Frame-Options, che copriva solo i casi DENY e SAMEORIGIN; averla è la difesa moderna contro il clickjacking.default-src è il fallback per script-src, style-src, img-src, connect-src, font-src e simili quando queste mancano. Attenzione però: alcune direttive importanti NON ricadono sotto default-src, in particolare frame-ancestors, base-uri e form-action. Vanno sempre dichiarate a parte, altrimenti restano prive di restrizioni anche con un default-src stretto.add_header Content-Security-Policy "..."; in Nginx, Header set Content-Security-Policy "..." in Apache, oppure un middleware nel framework applicativo. In alternativa puoi usare <meta http-equiv="Content-Security-Policy" content="..."> nell'HTML, ma il meta tag ha limiti: non supporta frame-ancestors né report-uri e va posizionato prima di qualsiasi risorsa. Per una protezione completa usa l'header.'strict-dynamic' gli host e le wildcard nella stessa direttiva vengono ignorati dai browser che la supportano.report-uri attivo e osserva le violazioni reali generate dal traffico degli utenti per qualche giorno. Ogni report indica la direttiva violata e la risorsa bloccata: usali per allargare la policy solo dove serve davvero, preferendo nonce e host specifici alle wildcard. Quando il flusso di violazioni legittime si azzera, sostituisci l'header report-only con quello che blocca. Rigenera la versione finale nel builder e rivalidala prima del deploy.Questo tool compone e valida la policy, ma il deploy graduale di una CSP su un sito vivo (collaudo in report-only, analisi dei report di violazione, integrazione dei nonce nel middleware, hardening di Apache o Nginx) richiede metodo. Lavoro su VPS unmanaged dei principali provider europei e su infrastrutture aziendali on-prem.
Parliamo del tuo hardening CSP