Aggiungere security.txt in 5 minuti — un punto di partenza per la divulgazione delle vulnerabilità | Scanthra

Scanthra · 6 min di lettura · Aggiornato Maggio 2026

Cosa è davvero security.txt

security.txt è un piccolo file di testo semplice leggibile da macchina che pubblichi sul tuo sito web. È l'equivalente del mondo della sicurezza di robots.txt: una posizione nota, una sintassi semplice, e uno scopo chiaro. Il suo compito è rispondere a una domanda per qualcuno che pensa di aver appena trovato una vulnerabilità sul tuo sito — "a chi lo dico, e come?"

Il formato è standardizzato in IETF RFC 9116 ("A File Format to Aid in Security Vulnerability Disclosure"). È diventato uno Standard Proposto nel 2022, quindi non è più una bozza o una stranezza — è il modo concordato per farlo.

Perché è importante anche se non sei una banca

Tre motivi per cui vale i cinque minuti:

• I ricercatori possono contattarti. Senza un canale chiaro, chi trova il problema o si arrende, lo pubblica pubblicamente, o martella il tuo modulo di contatto generico. Un indirizzo documentato cattura il problema tempestivamente, in privato.
• I questionari di approvvigionamento lo aspettano. I questionari di sicurezza vendor (SIG, CAIQ, quelli enterprise personalizzati) e le checklist a forma di NIS2 (direttiva UE sulla cybersecurity) chiedono sempre più spesso "hai una politica di divulgazione delle vulnerabilità?". Un security.txt attivo è il "sì" più economico possibile.
• Segnala maturità. Un sito con un security.txt aggiornato sembra uno il cui proprietario ha pensato a cosa succede quando qualcosa va storto. Questo da solo ti fa uscire dall'ultimo quartile.

I campi che RFC 9116 definisce

Solo Contact e Expires sono obbligatori. Il resto è opzionale ma utile.

• Contact: — obbligatorio. Uno o più modi per contattarti: un'e-mail (preceduta da mailto:), un numero di telefono (tel:), o un URL di segnalazione (https://). Sono consentite più righe Contact; elencale in ordine di preferenza.
• Expires: — obbligatorio. Un timestamp ISO 8601 dopo il quale questo file non dovrebbe più essere considerato attendibile. La maggior parte dei team lo imposta 6–12 mesi nel futuro e lo rinnova con un promemoria sul calendario.
• Encryption: — un URL alla tua chiave pubblica PGP, se vuoi segnalazioni crittografate. Opzionale ma apprezzato.
• Acknowledgments: — un URL a una pagina che ringrazia i ricercatori che hanno segnalato problemi in modo responsabile. Piccola buona karma.
• Preferred-Languages: — tag di lingua BCP 47 separati da virgola (ad esempio it, en). Puoi ometterlo — la maggior parte dei team capisce l'inglese più la propria lingua comunque.
• Canonical: — l'URL canonico di questo file. Utile se il tuo sito è raggiungibile su più hostname; dice ai parser quale copia è autorevole.
• Policy: — un URL alla tua politica completa di divulgazione delle vulnerabilità: perimetro, linguaggio di safe harbour, tempo di risposta atteso.
• Hiring: — un URL alla pagina dei lavori del tuo team di sicurezza. Sì, è nella specifica.
• CSAF: — un URL a un CSAF 2.0 file di metadati del provider. Rilevante solo se pubblichi advisory leggibili da macchina; le piccole imprese possono ignorarlo.

Un esempio da copiare e incollare che puoi davvero usare

Sostituisci l'e-mail, le date e gli URL con i tuoi. Mantieni il file in ASCII semplice (no BOM) e usa terminazioni di riga UNIX. Le righe che iniziano con # sono commenti.

# security.txt for example.com
# Please report security issues using the contacts below.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-05-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

Dove metterlo

La posizione canonica è:

https://tuodominio.com/.well-known/security.txt

La posizione legacy /security.txt alla root del documento è tollerata dalla maggior parte degli strumenti, ma il percorso /.well-known/ è quello prescritto da RFC 9116 — usa quello.

nginx

location = /.well-known/security.txt {
    alias /var/www/example.com/.well-known/security.txt;
    default_type text/plain;
    add_header Cache-Control "public, max-age=3600";
}

Apache

<Files "security.txt">
    ForceType text/plain
    Header set Cache-Control "public, max-age=3600"
</Files>

Metti il file in /var/www/example.com/.well-known/security.txt e assicurati che Apache sia autorizzato a servire directory nascoste (alcune configurazioni predefinite bloccano i percorsi con prefisso .).

Host statici, WordPress, Cloudflare Pages, Vercel, Netlify

Metti un file chiamato security.txt in una cartella chiamata .well-known nella directory degli asset pubblici e ridistribuisci. La maggior parte degli host statici serve le directory dotfile felicemente; verifica visitando l'URL subito dopo il deployment.

Firmalo (opzionale ma ordinato)

RFC 9116 permette che il file sia un messaggio PGP con firma chiara. La maggior parte delle piccole imprese non si preoccupa — e va bene così. Se già pubblichi una chiave PGP, la firma rende più difficile per qualcuno falsificare il file tramite un host compromesso. Se non lo fai, saltalo; un file non firmato è perfettamente valido.

Errori comuni da evitare

• Expires mancante. Una riga Expires scaduta o assente rende il file non valido per la specifica. I parser avvertiranno o lo rifiuteranno.
• Tipo MIME sbagliato. Il file deve essere servito come text/plain; a volte un web server restituisce application/octet-stream e rompe il parsing.
• Solo HTTPS. security.txt deve essere servito su HTTPS al suo URL canonico. Una versione HTTP semplice viene ignorata.
• Posta in arrivo personale in Contact. Usa un indirizzo di ruolo come security@ che sopravvive ai cambi di personale, non mario@.
• Rinnovo dimenticato. Metti la data Expires sullo stesso calendario in cui rinnovi i certificati TLS. Un security.txt scaduto è peggio di nessuno — dice ai ricercatori che il team non è attento.

Come Scanthra rileva questo

Il nostro probe M10 robots e well-known controlla se /.well-known/security.txt esiste e è raggiungibile sull'URL canonico HTTPS. Se manca, lo segnaliamo come una osservazione a bassa gravità piuttosto che come un problema rilevato — è un "bello avere, non una ferita" — e includiamo questa guida come correzione suggerita. I siti che già pubblicano un file valido ricevono un discreto pollice su nella mappa di conformità.