Generatore di Content Security Policy (CSP)

Q: 'unsafe-inline' in style-src è un problema?

È meno pericoloso che in script src e molto diffuso, perché tante librerie impostano stili inline. Un CSS iniettato può comunque deturpare una pagina o far trapelare dati, quindi l'analisi lo segnala con gravità bassa.

Q: Perché la policy blocca i miei script inline?

Appena script src è impostato senza 'unsafe inline' , ogni <script inline e ogni attributo onclick= vengono bloccati. Sposta il codice in un file oppure aggiungi un nonce o un hash.

Crea l'header Content-Security-Policy, il tag meta e la versione Report-Only con preset, nonce e hash SHA-256, e analizza una policy esistente.

Parti da un preset

Gli host Google sono esempi tratti dalle indicazioni CSP di Google per il tag Google. Google li cambia di tanto in tanto: controlla la documentazione aggiornata e rimuovi quello che non usi.

Direttive

Sorgenti separate da spazi. Lascia vuoto un campo per omettere la direttiva (le direttive di fetch ricadono allora su default-src).

default-srcValore di riserva per le altre direttive di fetch script-srcJavaScript style-srcFogli di stile e stili inline img-srcImmagini e favicon connect-srcfetch, XHR, WebSocket, EventSource font-srcWeb font frame-srcPagine che incorpori in iframe worker-srcWeb worker e service worker media-srcAudio e video object-srcPlugin (<object>, <embed>): usa 'none' base-uriValori consentiti per <base href> form-actionDove si possono inviare i moduli frame-ancestorsChi può incorporare la tua pagina (clickjacking)

Aggiunta rapida Direttiva

Un nonce deve essere un nuovo valore casuale a ogni risposta, generato dal tuo server e ripetuto in ogni <script nonce="…">. Un nonce fisso non protegge nulla.

Calcola l'hash di uno script o stile inline Codice inline, oppure HTML con elementi <script>/<style>

Aggiungi a

L'hash copre il testo esatto tra i tag, spazi e a capo compresi: ogni modifica richiede un nuovo hash. Anche i gestori di eventi inline (onclick=…) richiedono 'unsafe-hashes'.

upgrade-insecure-requests (carica le risorse http:// tramite https://)

Segnalazioni delle violazioni URL dell'endpoint per le segnalazioni (facoltativo) Nome del gruppo report-to

Aggiunge report-uri (browser meno recenti) e report-to con un header Reporting-Endpoints.

Header HTTP

Header Report-Only (prova senza bloccare)

Tag HTML <meta>

In un tag <meta> i browser ignorano frame-ancestors, report-uri, report-to e sandbox, e Report-Only non è supportato. Metti il tag all'inizio di <head>: vale solo per il contenuto che viene dopo.

Analisi di questa policy

Valuta una policy esistente

Incolla una policy, una riga di header o un tag <meta>

Come creare una policy

Scegli un punto di partenza in Parti da un preset: Rigoroso (nonce + strict-dynamic), Sito statico blindato, Sito web tipico oppure Tipico + Google Analytics / Ads. L’editor si apre con il preset del sito web tipico.
Regola le Direttive. Ogni campo accetta sorgenti separate da spazi; un campo vuoto esclude la direttiva.
Con Aggiunta rapida aggiungi una parola chiave alla Direttiva scelta: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data:… Aggiungi un nonce inserisce un nonce casuale a 128 bit.
Per consentire uno specifico script inline senza 'unsafe-inline', incollalo (o l’HTML che lo contiene) in Calcola l’hash di uno script o stile inline e clicca Calcola SHA-256 e aggiungi.
Spunta upgrade-insecure-requests se alcuni vecchi URL usano ancora http:// e, se vuoi, inserisci un URL dell’endpoint per le segnalazioni.
Copia l’Header HTTP, l’Header Report-Only o il Tag HTML . L’Analisi di questa policy si aggiorna mentre scrivi.

Per controllare una policy che hai già, incollala in Valuta una policy esistente e clicca Valuta la policy; Carica nell’editor la copia nei campi.

A cosa serve una Content Security Policy

Una CSP indica al browser da quali origini una pagina può caricare script, stili, immagini, font, frame e connessioni. Il suo compito principale è limitare il cross-site scripting (XSS): anche se un attaccante riesce a iniettare markup nella tua pagina, una buona policy impedisce allo script iniettato di essere eseguito. Controlla inoltre chi può incorporare la tua pagina in un frame (frame-ancestors), verso dove possono essere inviati i moduli (form-action) e a cosa può puntare <base> (base-uri).

Le direttive di fetch come img-src o font-src ricadono su default-src quando mancano. base-uri, form-action e frame-ancestors invece non hanno valore di riserva: per questo l’analisi le richiede esplicitamente.

Nonce, hash e strict-dynamic

Consentire degli host (script-src https://cdn.example.com) sembra sicuro, ma spesso si può aggirare: i grandi domini ospitano endpoint JSONP e vecchie librerie che un attaccante può riutilizzare. L’approccio raccomandato dai team di sicurezza dei browser è una CSP rigorosa: ogni <script> legittimo porta un nonce generato dal server per ogni risposta, oppure è consentito tramite il suo hash, e 'strict-dynamic' permette a questi script attendibili di caricare gli script di cui hanno bisogno. In questa configurazione https: e 'unsafe-inline' sono solo valori di riserva per browser molto vecchi; quelli moderni li ignorano.

Un nonce funziona solo se cambia a ogni risposta ed è imprevedibile. Quello inserito da Aggiungi un nonce è un esempio: il tuo server o il tuo framework deve generarne uno proprio. Un hash copre i byte esatti del codice inline, quindi se riformatti lo script ti serve un nuovo hash.

Header, Report-Only e tag meta

Quando puoi, invia la policy come header di risposta HTTP. Distribuiscila prima come Content-Security-Policy-Report-Only: i browser segnalano le violazioni (nella console e al tuo endpoint, se ne hai impostato uno) senza bloccare nulla, così puoi sistemare le pagine prima di applicarla davvero. Le impostazioni delle segnalazioni aggiungono report-uri per i browser meno recenti e report-to con un header Reporting-Endpoints.

La versione <meta http-equiv> è comoda sugli hosting statici, ma i browser vi ignorano frame-ancestors, report-uri, report-to e sandbox, e non esiste un tag meta Report-Only. Lo strumento toglie queste direttive dal tag e te lo segnala.

Tutto viene calcolato nel tuo browser: la policy e il codice che incolli non vengono inviati a nessun server.

Domande frequenti

'unsafe-inline' in style-src è un problema?

È meno pericoloso che in script-src e molto diffuso, perché tante librerie impostano stili inline. Un CSS iniettato può comunque deturpare una pagina o far trapelare dati, quindi l’analisi lo segnala con gravità bassa.

Gli host di Google Analytics sono completi?

Sono esempi tratti dalle indicazioni CSP di Google per il tag Google. Google li modifica nel tempo e possono servire domini regionali: controlla la documentazione aggiornata di Google e rimuovi quello che non usi. Anche lo snippet inline di gtag.js ha bisogno di un nonce o di un hash.

Perché la policy blocca i miei script inline?

Appena script-src è impostato senza 'unsafe-inline', ogni <script> inline e ogni attributo onclick= vengono bloccati. Sposta il codice in un file oppure aggiungi un nonce o un hash.

Una CSP sostituisce l'escape dell'input degli utenti?

No. Una CSP è una seconda linea di difesa. Continua a fare l’escape dell’output e a validare l’input; la policy limita i danni quando qualcosa sfugge.

Posso avere più policy?

Sì: se una pagina riceve più header CSP, una risorsa deve rispettarli tutti. Incolla una policy alla volta nello strumento di valutazione.