Parte 5 della serie "Sicurezza web UE: 10 passi verso un rating migliore"
Perché security.txt
Un ricercatore di sicurezza trova una vulnerabilità sul vostro sito. Chi contatta?
Senza security.txt: cerca nel sito, trova info@, invia un'e-mail. Finisce al marketing, viene cancellata come spam o ignorata. La vulnerabilità resta aperta.
Con security.txt: visita /.well-known/security.txt, trova il contatto di sicurezza, la chiave PGP e la policy di divulgazione. La segnalazione raggiunge il team giusto immediatamente.
Tasso di adozione nell'UE: 2,8%. Eppure: i siti con security.txt ottengono in media un punteggio superiore del 31% rispetto a quelli senza.
La correlazione
| Metrica | CON security.txt | SENZA | Fattore |
|---|---|---|---|
| Punteggio composito | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8x |
| CSP | 47% | 10% | 4,7x |
| Voto F | 6% | 44% | 7 volte meno |
security.txt non è la soluzione a tutto. Ma chi si prende il tempo di configurarlo ha di solito curato anche tutto il resto.
Come configurare security.txt
Passaggio 1: creare il file
Create /.well-known/security.txt sul vostro web server:
Contact: mailto:security@vostro-dominio.com
Expires: 2027-04-13T00:00:00.000Z
Preferred-Languages: it
Campi obbligatori (RFC 9116):
- Contact: — indirizzo e-mail o URL per le segnalazioni di sicurezza
- Expires: — data di scadenza (max 1 anno nel futuro)
Campi opzionali:
- Encryption: — chiave PGP per segnalazioni crittografate
- Acknowledgments: — hall of fame per i segnalatori responsabili
- Canonical: — URL canonico del file
- Policy: — link alla vostra Vulnerability Disclosure Policy
- Hiring: — link alle posizioni aperte nel settore sicurezza
Passaggio 2: renderlo accessibile
Il file deve essere raggiungibile all'indirizzo https://vostro-dominio.com/.well-known/security.txt. Per la maggior parte delle configurazioni:
Nginx:
location = /.well-known/security.txt {
alias /var/www/vostro-dominio.com/security.txt;
}
Apache: posizionate semplicemente il file in /.well-known/ nella document root.
WordPress: usate il plugin "WP Security.txt" o posizionate manualmente il file in .well-known/ nella webroot.
Passaggio 3: fornire una chiave PGP (raccomandato)
Contact: mailto:security@vostro-dominio.com
Encryption: https://vostro-dominio.com/.well-known/pgp-key.txt
Expires: 2027-04-13T00:00:00.000Z
L'ENISA raccomanda l'opzione di crittografia per consentire ai segnalatori di inviare dettagli sensibili in modo protetto.
Adozione per settore
| Settore | Adozione | Punteggio medio con | Punteggio medio senza |
|---|---|---|---|
| Banche | 23,9% | 69 | 55 |
| E-Commerce | 15,6% | 64 | 53 |
| Istruzione | 8,1% | 53 | 42 |
| Tecnologia | 5,3% | 63 | 45 |
| Sanità | 2,0% | 58 | 42 |
| Ospitalità | 1,1% | 51 | 40 |
Le banche sono in testa — quasi una banca su quattro ha security.txt. L'ospitalità (hotel, ristoranti) è all'1,1%.
Contesto normativo
- NIS2 Art. 21(2)(e) richiede esplicitamente "la gestione e la divulgazione delle vulnerabilità" — security.txt è il meccanismo standardizzato per questo
- CRA Art. 14 — la divulgazione coordinata delle vulnerabilità diventa obbligatoria da dicembre 2027 per i produttori di prodotti digitali
- ENISA indica security.txt come best practice per la divulgazione delle vulnerabilità
- CERT nazionali in tutta Europa (CSIRT Italia, ANSSI, BSI, NCSC-NL) raccomandano o utilizzano security.txt sui propri domini
Errori comuni
1. Dimenticare Expires. Senza Expires, il file non è valido secondo l'RFC 9116. Impostatelo a 1 anno nel futuro e mettete un promemoria per aggiornarlo.
2. HTTP invece di HTTPS. Il file deve essere servito tramite HTTPS — un security.txt non crittografato potrebbe essere manomesso.
3. info@ come contatto. Contact: mailto:info@... finisce al marketing. Create un indirizzo security@ dedicato che raggiunga una persona responsabile della sicurezza.
Verifica il tuo security.txt
La prossima settimana nella Parte 6: DKIM — perché solo il 31% dei domini UE firma le proprie e-mail.