Analizzatore CSP

Analizza Content-Security-Policy (CSP) e Content-Security-Policy-Report-Only per qualsiasi URL. Rileva direttive rischiose (unsafe-inline, caratteri jolly), strategie mancanti nonce/hash, pattern deprecati e fornisce raccomandazioni pratiche per rafforzare le difese XSS. Supporta reindirizzamenti, ispezione intestazioni grezze, filtraggio, risultati ed esportazione JSON/PDF.

Loading…

Informazioni Analizzatore CSP

Incolla un URL per ispezionare le sue intestazioni CSP e vedere rapidamente se la policy ti protegge effettivamente da XSS e injection. Questo analizzatore evidenzia autorizzazioni pericolose (come unsafe-inline o caratteri jolly ampi), spiega cosa manca (strategia nonce/hash, restrizioni frame) e ti aiuta a passare a una CSP pratica e distribuibile usando report-only in sicurezza.

Funzionalità

  • Rileva e spiega le intestazioni Content-Security-Policy e Content-Security-Policy-Report-Only.
  • Segnala le trappole comuni CSP: unsafe-inline, unsafe-eval, caratteri jolly ampi e fonti eccessivamente permissive.
  • Guida per un'esecuzione più sicura di script/stili tramite strategie basate su nonce e hash.
  • Identifica direttive mancanti che spesso contano nel rafforzamento reale (es. frame-ancestors, object-src, base-uri).
  • Approfondimenti Report-Only: comprendi cosa verrebbe bloccato e come implementare CSP senza interrompere la produzione.
  • Segue i reindirizzamenti (fino a 10) per analizzare la policy di risposta finale applicata dai browser.
  • Vista intestazioni grezze per l'output esatto del server e il debug.
  • Risultati + scheda punteggio con filtraggio "solo problemi".
  • Esporta l'analisi in JSON o PDF per audit, ticket e revisioni di sicurezza.
  • Include consapevolezza delle intestazioni deprecate per individuare policy legacy e necessità di migrazione.

🧭 Come usare for csp-analyzer

1

Inserisci l'URL da analizzare

Incolla l'URL della pagina che desideri controllare (spesso la tua homepage o il guscio dell'app).

2

Abilita il seguito dei reindirizzamenti se necessario

Mantieni "Segui Reindirizzamenti" abilitato in modo che l'analizzatore raggiunga la destinazione finale HTTPS/www/locale dove viene restituita la CSP reale.

3

Rivedi la scheda punteggio e i risultati

Inizia con i risultati per individuare rischi critici (unsafe-inline, caratteri jolly, restrizioni mancanti) e comprendere quali direttive influenzano il punteggio.

4

Ispeziona le intestazioni grezze durante il debug

Attiva "Mostra Intestazioni Grezze" per verificare i nomi/valori esatti delle intestazioni (utile se sono presenti più intestazioni CSP o un proxy/CDN le modifica).

5

Esporta un report per il tuo flusso di sicurezza

Scarica JSON per l'automazione o PDF per audit di sicurezza e ticket di ingegneria.

Specifiche tecniche

Modello di richiesta

Questo strumento esegue un'ispezione delle intestazioni URL e si concentra sull'analisi delle intestazioni di sicurezza, incluse le policy CSP e report-only.

ImpostazioneComportamentoPredefinito
Segui ReindirizzamentiSegue la catena di reindirizzamento per analizzare la politica effettiva restituita dall'URL finaleAbilitato
Reindirizzamenti MassimiLimite di reindirizzamenti per prevenire loop10
TimeoutLimite di timeout della richiesta15000 ms
User-AgentIdentifica l'agente utente della richiestaEncode64Bot/1.0 (+https://encode64.com)
Reti privateBlocca l'accesso agli intervalli di rete privati per sicurezzaDisabilitato (reti private non consentite)

Intestazioni CSP ispezionate

L'analizzatore verifica sia le politiche di applicazione che quelle non applicative e le presenta in una forma leggibile.

IntestazioneSignificato
Content-Security-PolicyPolitica applicata forzatamente dal browser
Content-Security-Policy-Report-OnlyPolitica non bloccante che segnala le violazioni (utile per il rollout e la messa a punto)
I siti possono emettere più intestazioni CSP. I browser applicano regole di combinazione/precedenza che possono essere complesse—le intestazioni grezze aiutano a confermare ciò che viene inviato.

Cosa cerca l'analisi

I risultati si basano su controlli pratici di rafforzamento CSP e su errori comuni di distribuzione.

AreaEsempi di risultati
Robustezza della politica degli scriptuso di unsafe-inline / unsafe-eval, sorgenti con caratteri jolly, strategia nonce/hash mancante
Robustezza della politica degli stilistili unsafe-inline, sorgenti troppo ampie, percorso di migrazione a nonce/hash mancante dove fattibile
Resistenza al framing e al clickjackingRestrizioni frame mancanti o deboli (spesso tramite frame-ancestors)
Pattern legacy / deprecatiDirettive o pattern vecchi che dovrebbero essere modernizzati
Pronto per il rolloutVisibilità della presenza Report-Only e degli endpoint di segnalazione

Riga di comando

Usa questi comandi per ispezionare rapidamente gli header CSP. Sono utili per validare quanto riportato dall'analizzatore.

macOS / Linux

Recupera gli header di risposta (cerca CSP)

curl -I https://example.com

Ispeziona Content-Security-Policy e Content-Security-Policy-Report-Only negli header di risposta.

Segui i reindirizzamenti mentre controlli gli header

curl -IL https://example.com

Assicura di vedere gli header CSP dalla destinazione finale (HTTPS, www, app shell route).

Mostra solo gli header CSP (corrispondenza case-insensitive)

curl -I https://example.com | grep -i "content-security-policy"

Isola rapidamente gli header CSP e report-only dal set completo di header.

Windows (PowerShell)

Ispeziona gli header CSP

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Visualizza gli header CSP di enforcement e report-only se presenti.

Distribuisci prima le nuove policy in modalità Report-Only, rivedi i report delle violazioni, poi stringi e applica. L'ottimizzazione del CSP è iterativa per le app moderne.

Casi d'uso

Irrobustisci un sito contro XSS

Usa il CSP per ridurre l'impatto delle vulnerabilità di injection, limitando da dove possono caricarsi script/stili e come viene gestito il codice inline.

  • Identifica unsafe-inline/unsafe-eval e pianifica una migrazione a nonce/hash
  • Limita le origini script-src/style-src a origini attendibili
  • Aggiungi direttive difensive mancanti (base-uri, object-src, frame-ancestors)

Distribuisci il CSP in sicurezza con Report-Only

Introduci il CSP gradualmente senza interrompere la produzione, iniziando con Content-Security-Policy-Report-Only e iterando sulle violazioni.

  • Rileva la presenza di policy report-only
  • Comprendi cosa verrebbe bloccato prima dell'applicazione
  • Esporta un report per il tuo piano di rollout e i ticket

Debug di script, iframe o widget di terze parti non funzionanti

Un CSP eccessivamente restrittivo può bloccare analisi, embed o connessioni API. Usa l'analizzatore per vedere cosa la policy consente e dove potresti aver bisogno di origini esplicite.

  • Conferma le origini consentite per script/img/connect/frame
  • Rileva wildcard troppo ampie aggiunte come soluzione rapida
  • Sostituisci autorizzazioni ampie con domini mirati

Revisione della sicurezza / evidenza di conformità

Genera un report coerente della postura CSP attuale per revisioni di sicurezza, questionari client o conformità interna.

  • Scarica JSON per tracciare le modifiche nel tempo
  • Scarica PDF per artefatti di audit e condivisione

❓ Frequently Asked Questions

Cos'è il CSP e da cosa protegge?

Content Security Policy (CSP) è un livello di sicurezza applicato dal browser che limita da dove le risorse possono essere caricate e come gli script/stili vengono eseguiti. Viene principalmente utilizzato per ridurre l'impatto di cross-site scripting (XSS) e attacchi di iniezione.

Qual è la differenza tra CSP e CSP Report-Only?

Content-Security-Policy viene applicato (può bloccare). Content-Security-Policy-Report-Only non blocca; segnala le violazioni in modo da poter ottimizzare una policy prima di applicarla.

Perché unsafe-inline è considerato pericoloso?

unsafe-inline consente script/stili in linea, il che indebolisce la capacità del CSP di bloccare codice iniettato. Approcci più sicuri utilizzano nonce o hash per consentire solo blocchi in linea noti, bloccando comunque iniezioni impreviste.

Ho bisogno di nonce o hash?

Se la tua app utilizza script o stili in linea, nonce/hash sono il metodo moderno per mantenere efficace il CSP senza interrompere le funzionalità. Consentono blocchi in linea specifici prevenendo iniezioni arbitrarie.

Un CDN o un proxy può modificare il mio header CSP?

Sì. I livelli di edge possono aggiungere, unire o sovrascrivere gli header. Se qualcosa appare incoerente, abilita gli header raw e segui i reindirizzamenti per verificare gli header di risposta finali.

Il CSP sostituisce la correzione dei bug XSS?

No. Il CSP è un controllo di difesa in profondità. Hai ancora bisogno di una corretta codifica dell'output, templating sicuro e validazione dell'input. Il CSP riduce il raggio di impatto se qualcosa sfugge.

È sicuro incollare URL qui?

Lo strumento effettua richieste lato server all'URL fornito e blocca i target di rete privata. Evita di inserire segreti negli URL (come token nelle query string) e preferisci URL pubblici di cui ti fidi.

Pro Tips

Best Practice

Inizia con Content-Security-Policy-Report-Only, raccogli le violazioni, poi stringi e applica. Il CSP è iterativo per le app reali.

Best Practice

Sostituisci unsafe-inline con una strategia nonce o hash. Mantieni le policy esplicite e minime.

Best Practice

Aggiungi frame-ancestors per ridurre il rischio di clickjacking ed evita di fare affidamento solo su header legacy.

Best Practice

Evita wildcard ampi come soluzione rapida. Preferisci domini mirati per script/immagini/connessioni e rivedi le esigenze di terze parti.

Best Practice

Esporta un report JSON e traccia le modifiche CSP nel CI per individuare regressioni quando gli header vengono modificati da aggiornamenti CDN/app.

Additional Resources

Other Tools