Analizzare gli header di sicurezza di un sito è la parte facile. Cinque minuti con curl e hai tutto.
La parte difficile è trasformare quell'output in qualcosa che un cliente capisce, approva e paga.
In questo articolo ti mostro il processo completo: dagli header che contano davvero, al perché uno score sintetico cambia la conversazione, fino a come impacchettare il tutto in un deliverable presentabile.
Il problema: il terminale non è un deliverable
Ecco cosa ottieni con un comando:
curl -sI https://example.com | grep -i "strict-transport\|content-security\|x-frame"
strict-transport-security: max-age=31536000
content-security-policy: default-src 'self'
Tecnicamente completo. Praticamente inutile da consegnare.
Il cliente non tecnico si chiede tre cose, in quest'ordine:
- Sono a rischio? (sì/no, quanto)
- Cosa manca esattamente?
- Quanto costa sistemarlo?
Un dump di header non risponde a nessuna delle tre. Serve una struttura.
I 15 header che valuto, e quanto pesano
Non tutti gli header hanno lo stesso impatto. Questo è il sistema di pesi che uso, su un totale di 82 punti:
| Header | Peso | Cosa previene |
|---|---|---|
Strict-Transport-Security |
10 | Downgrade a HTTP, SSL stripping |
Content-Security-Policy |
10 | XSS, injection di script terzi |
X-Content-Type-Options |
8 | MIME sniffing |
X-Frame-Options |
8 | Clickjacking |
Cross-Origin-Opener-Policy |
7 | Attacchi cross-window |
X-XSS-Protection |
6 | Filtro XSS legacy del browser |
Referrer-Policy |
6 | Leak di URL sensibili |
Permissions-Policy |
6 | Accesso non richiesto a camera/mic |
Cross-Origin-Resource-Policy |
5 | Hotlinking di risorse |
Cross-Origin-Embedder-Policy |
5 | Embedding non autorizzato |
Expect-CT |
4 | Certificati fraudolenti |
X-Permitted-Cross-Domain-Policies |
3 | Policy cross-domain legacy |
X-DNS-Prefetch-Control |
2 | Leak DNS |
X-Download-Options |
2 | Download automatici su IE |
X-Powered-By |
−5 | Information disclosure (va rimosso) |
Nota l'ultimo: X-Powered-By è l'unico con peso negativo. Se c'è, ti dice quale stack e quale versione stai usando. È un regalo a chi cerca CVE noti.
# nginx
server_tokens off;
proxy_hide_header X-Powered-By;
// Express
app.disable('x-powered-by');
// oppure, meglio, usa helmet che lo fa da solo
app.use(helmet());
Perché lo score sintetico cambia tutto
Somma i pesi degli header presenti, dividi per 82, converti in lettera:
| Percentuale | Grade |
|---|---|
| ≥ 90% | A+ |
| ≥ 80% | A |
| ≥ 70% | B |
| ≥ 60% | C |
| ≥ 50% | D |
| < 50% | F |
Sembra banale. Non lo è, per un motivo puramente umano: "il tuo sito è D" apre una conversazione, "manca Cross-Origin-Embedder-Policy" la chiude.
Il grade dà al cliente un punto di riferimento immediato e — cosa più importante — un obiettivo. Da D a B è un lavoro concreto, misurabile, preventivabile. "Aggiungi questi header" no.
Piccolo dato che spiazza sempre: se provi i grandi siti, quasi nessuno prende A+. GitHub sta intorno a D (59%). Google fa F. Non perché siano insicuri — hanno difese a più livelli — ma perché gli header sono solo un livello. Farlo vedere al cliente lo rassicura e allo stesso tempo lo motiva: "puoi fare meglio di GitHub in un pomeriggio".
Le tre categorie di priorità
Un report con 9 header mancanti tutti allo stesso livello è un report che nessuno implementa. Serve ordinare per impatto:
🔴 Priorità alta — peso ≥ 8
HSTS, CSP, X-Content-Type-Options, X-Frame-Options. Sono quelli che bloccano attacchi reali e frequenti. Si fanno subito.
🟠 Priorità media — peso 5–7
Famiglia Cross-Origin, Referrer-Policy, Permissions-Policy. Importanti, ma richiedono test: COEP: require-corp può rompere risorse esterne, e va verificato.
🟡 Priorità bassa — peso < 5
Header legacy e di rifinitura. Si aggiungono per arrivare ad A+, non per fermare un attacco.
Raggruppare così trasforma una lista di 9 problemi in tre task. Un cliente approva tre task. Nove no.
Il deliverable: cosa cambia tra buono e ignorato
Ho consegnato report in tre formati diversi e la differenza di risposta è netta.
| Formato | Cosa succede |
|---|---|
| Screenshot del terminale | Il cliente ringrazia e non fa nulla |
| Markdown / email | Viene letto, poi si perde nel thread |
| PDF con score, grafici e priorità | Viene inoltrato al management e approvato |
Il PDF vince perché è condivisibile. La persona con cui parli non è quasi mai quella che decide il budget. Un PDF con un cerchio "D" ben visibile in prima pagina arriva al decisore senza che tu debba spiegare niente.
Cosa metto dentro, in ordine:
- Score circle grande e colorato in alto — l'unica cosa che tutti guardano
- Grafico a torta presenti vs mancanti — colpo d'occhio immediato
- Barre per categoria (Transport, CSP, Cross-Origin, Privacy…) — mostra dove è il buco
- Tabella completa con header, stato, valore attuale e fix esatto da incollare
- Raccomandazioni raggruppate per le tre priorità
Il punto 4 è quello che fa la differenza per il dev che riceve il report: non "manca HSTS", ma max-age=31536000; includeSubDomains; preload pronto da copiare.
E se devi controllare più domini — un'agenzia con 20 clienti, un'infrastruttura con più sottodomini — serve anche un bulk scan con confronto dei punteggi. Altrimenti passi il pomeriggio a rifare la stessa cosa 20 volte.
Il tool: free e Pro
Ho costruito entrambe le parti di questo workflow.
🆓 Versione free — open source
Analisi dei 15 header, score, raccomandazioni. Codice MIT su GitHub, demo online.
Perfetta per controllare i tuoi progetti.
💎 Versione Pro — €9
È la parte "deliverable" descritta sopra, pronta all'uso:
- Report PDF professionale con score circle, grafico a torta, barre per categoria e tabella completa
- Export CSV con statistiche, distribuzione per categoria e raccomandazioni prioritarie
- Bulk Scan fino a 50 domini in una volta, con confronto grafico dei punteggi
- Codice sorgente completo (Node.js + Python), self-hosted, licenza MIT
- Pagamento una volta sola, aggiornamenti a vita
→ Security Headers Checker Pro — €9
Se fai security audit per clienti, si ripaga al primo report consegnato.
In sintesi
Il valore non è nell'analisi — quella la fa curl. Il valore è in tre cose:
- Uno score che dà un punto di riferimento e un obiettivo
- Priorità che riducono 9 problemi a 3 task approvabili
- Un formato condivisibile che arriva a chi decide il budget
Il resto è impacchettamento. Ma è l'impacchettamento che viene pagato.
Se hai domande sugli header o sul processo, scrivimi nei commenti. E se il progetto free ti è utile, una stella su GitHub aiuta molto. ⭐
Top comments (0)