Sicurezza

Quali header di sicurezza invia realmente il vostro sito?

Gli header di sicurezza rappresentano la protezione più economica ed efficace disponibile: poche righe di configurazione del server che neutralizzano intere classi di attacchi. La maggior parte dei siti non ne invia alcuno. Questo strumento legge le vostre risposte HTTP e ne valuta la robustezza.

Inviamo una singola richiesta HTTP ed esaminiamo gli header di risposta. Nessun dato viene memorizzato.

Gli header visualizzati provengono dalla risposta HTTP reale inviata dal vostro server alla nostra richiesta. La valutazione si conforma alle raccomandazioni OWASP Secure Headers. Un header assente viene segnalato come mancante; un valore vulnerabile viene evidenziato spiegandone la ragione specifica.

La guida dietro questo strumento Header di sicurezza HTTP: cosa fa ciascuno Sei header che bloccano intere categorie di attacchi, in ordine di priorità: funzionamento, errori comuni e i due da rimuovere definitivamente. Leggi la guida · 7 min di lettura →

Cosa verifica questo strumento

Otto intestazioni lette dalla vostra risposta HTTP reale e valutate rispetto alle direttive OWASP — comprese due che dovreste rimuovere.

  • Strict-Transport-Security (HSTS)

    Verifica se HTTPS è imposto, per quale durata e se include i sottodomini.

  • Content-Security-Policy (CSP)

    Verifica se è attiva, in modalità report-only e se la presenza di 'unsafe-inline' ne vanifica l'efficacia.

  • Protezione da clickjacking

    Verifica della presenza di X-Frame-Options o frame-ancestors in CSP per impedire l'incorporamento in iframe malevoli.

  • X-Content-Type-Options

    Un valore obbligatorio (nosniff), zero configurazione, nessun effetto collaterale. L'intervento correttivo più semplice.

  • Referrer-Policy

    Verifica se gli URL completi — inclusi parametri nelle query string — vengono esposti ai siti esterni verso cui cliccano gli utenti.

  • Permissions-Policy

    Dichiarazione delle funzionalità del browser accessibili agli script della pagina, compresi quelli di terze parti.

  • Divulgazione delle versioni software

    Presenza di header Server e X-Powered-By che espongono le versioni del software a scanner di vulnerabilità.

  • Header obsoleti

    X-XSS-Protection attivava un filtro rimosso dai browser moderni per vulnerabilità intrinseche.

Come interpretare i risultati

Iniziate con i tre che non possono rompere nulla: X-Content-Type-Options, X-Frame-Options e Referrer-Policy. Ciascuno è una singola riga, sicuro praticamente su qualsiasi sito e implementabile insieme questo pomeriggio.

Poi rimuovete ciò che non dovrebbe esserci. Eliminare X-XSS-Protection e nascondere gli header di versione richiede pochi minuti.

Poi HSTS, con cautela. È un vincolo che i browser applicano rigidamente e che non potete ritirare rapidamente. Verificate che ogni sottodominio sia servito in HTTPS, quindi aumentate max-age a scaglioni anziché saltare direttamente a un anno.

Infine CSP, prima in modalità report-only. È l'header più efficace in assoluto e l'unico che può rompere il vostro sito. Raccogliete le violazioni per due-quattro settimane, inserite in whitelist ciò che è legittimo, quindi passate all'applicazione vincolante.

Una precisazione onesta: nulla di tutto questo è un fattore di ranking diretto. Il motivo per farlo è che un sito compromesso perde posizionamenti rapidissimamente non appena Google lo segnala — e a quel punto dovrete rimediare a qualcosa di ben più costoso di un file di configurazione.

A cosa serve ciascuna intestazione di sicurezza

Strict-Transport-Security (HSTS)

Ordina al browser di connettersi a questo dominio esclusivamente tramite HTTPS per l'intervallo temporale specificato. Impedisce gli attacchi man-in-the-middle che potrebbero intercettare e degradare una prima richiesta su HTTP.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Iniziate con un valore breve di max-age finché non avrete accertato che ogni sottodominio funzioni correttamente in HTTPS. Una volta impostato un anno con includeSubDomains, l'impegno è vincolante — i browser rifiuteranno qualsiasi connessione HTTP semplice verso ogni sottodominio fino alla scadenza.

Content-Security-Policy (CSP)

L'intestazione più potente e complessa da implementare. Dichiara da quali origini la pagina è autorizzata a caricare script, fogli di stile, immagini e connessioni di rete, bloccando la maggior parte degli attacchi cross-site scripting (XSS) anche in presenza di un'iniezione riuscita.

Il motivo per cui pochi siti la implementano è che una CSP rigida blocca gli script inline, diffusissimi nella maggior parte dei siti web. L'approccio pratico consiste nel rilasciarla inizialmente in modalità report-only, raccogliere le violazioni per un paio di settimane e poi applicare il blocco effettivo.

X-Frame-Options

Impedisce che le vostre pagine vengano incorporate in un iframe su siti terzi, tecnica alla base degli attacchi di clickjacking — un riquadro invisibile sovrapposto a elementi su cui la vittima pensa di fare clic.

La direttiva frame-ancestors nella CSP ne costituisce l'evoluzione moderna, ma inviare entrambe non comporta costi e protegge anche i browser più datati.

X-Content-Type-Options: nosniff

Un solo valore fisso, zero configurazione, nessun effetto collaterale. Impedisce ai browser di reinterpretare il tipo MIME di un file quando appare difforme — il meccanismo sfruttato per spacciare file caricati per script eseguibili. Non esiste motivo per non inviarlo.

Referrer-Policy

Regola quali informazioni dell'URL corrente vengono trasmesse quando un utente clicca su un link verso un altro sito. In sua assenza, gli URL completi — inclusi token o parametri privati nelle query string — possono trapelare a terzi. strict-origin-when-cross-origin è il valore predefinito ottimale adottato anche dai browser moderni.

Permissions-Policy

Dichiara quali funzionalità del browser la pagina può attivare: fotocamera, microfono, geolocalizzazione, pagamenti. Disabilitare ciò che non viene utilizzato limita i danni potenziali derivanti dalla compromissione di uno script di terze parti.

Header che non dovreste più inviare

X-XSS-Protection è deprecato. Il filtro che attivava è stato rimosso da Chrome ed Edge perché introduceva vulnerabilità proprie. Inviarlo non serve a nulla e rivela una configurazione copiata da tutorial obsoleti.

Server e X-Powered-By pubblicizzano le versioni esatte dei vostri software, offrendo informazioni preziose a chiunque effettui scansioni automatiche alla ricerca di falle note. Rimuoveteli.

Domande frequenti

Gli header di sicurezza influenzano il posizionamento SEO?

Not directly. HTTPS è un fattore di ranking leggero e HSTS lo consolida, ma nessun motore valuta direttamente la presenza di CSP. La ragione per cui implementarli risiede nel fatto che un sito compromesso subisce crolli drastici e repentini di posizionamento non appena Google lo contrassegna come violato o veicolo di malware.

Vale la pena impegnarsi su CSP?

Per siti con aree riservate, pagamenti o gestione di dati personali, assolutamente sì. Per un sito vetrina essenziale, il rapporto tra sforzo e beneficio è meno favorevole e si ottiene la maggior parte della protezione dagli altri cinque header, implementabili con singole righe di codice.

Questi header rischiano di rompere il funzionamento del mio sito?

La CSP può farlo, motivo per cui è prevista la modalità report-only. HSTS costituisce un vincolo difficile da revocare istantaneamente, quindi aumentate il parametro max-age gradualmente. Tutti gli altri — nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy — possono essere aggiunti immediatamente e in totale sicurezza sulla quasi totalità dei siti.

Come posso aggiungerli su un hosting condiviso?

Modificando il file .htaccess su server Apache o LiteSpeed, la configurazione standard di quasi tutti gli hosting condivisi come Hostinger. È sufficiente un blocco `<IfModule mod_headers.c>` con una direttiva `Header always set` per ciascun parametro. Su Nginx si utilizza invece l'istruzione `add_header` all'interno del blocco server.

Altri strumenti gratuiti

Audit SEO e Velocità Pagina

Dati reali Core Web Vitals tramite le API di Google, più verifiche on-page dal vivo sul vostro HTML effettivo.

Diteci quali obiettivi volete raggiungere.

Un solo team. Tre uffici. Ventisei lingue. Inviateci il problema e riceverete una risposta tecnica qualificata — non un copione di vendita.

Richiedi un preventivo → Scrivici ora

Una proposta scritta entro un giorno lavorativo, nella vostra lingua.