Controllo security.txt
Inserisci un sito per vedere se dice ai ricercatori di sicurezza dove segnalare un problema, e se quel file è nel posto giusto, ben formato e ancora valido. Se non c’è, puoi scriverlo qui sotto.
Scrivi un security.txt
Compila ciò che ti riguarda e copia il risultato. Il file viene composto dentro questa pagina: niente di quello che scrivi qui ci viene inviato.
Un indirizzo e-mail o l’indirizzo https:// di un modulo. Usa una casella condivisa, non quella di una persona: le persone se ne vanno.
Una pagina che dice cosa si può testare e cosa può aspettarsi da te chi segnala.
Codici di lingua separati da virgole.
Aggiunge una riga Canonical, che lega il file al suo indirizzo.
Impostato a un anno da oggi, il massimo raccomandato dallo standard.
- Salva il testo in un file chiamato
security.txt, codificato in UTF-8. - Caricalo in una cartella chiamata
.well-knownalla radice del sito, così che risponda ahttps://your-domain/.well-known/security.txt. - Esegui il controllo qui sopra: il file deve tornare via HTTPS come
text/plain. - Segna la data di scadenza in un calendario. Un file scaduto è peggio di nessun file, perché sembra abbandonato.
Una porta d’ingresso per le cattive notizie
Prima o poi qualcuno esterno alla tua organizzazione nota qualcosa che non va nel tuo sito: una pagina che mostra gli ordini di altri clienti, un pannello di amministrazione dimenticato, un reset della password che si può riutilizzare. La maggior parte di queste persone vuole avvisarti. Il difficile è trovare a chi dirlo. Il modulo di contatto finisce alle vendite, la chat di assistenza chiede un numero d’ordine e nessuno risponde a info@.
Un file security.txt risolve proprio questo problema. Sono poche righe di testo semplice a un indirizzo fisso, /.well-known/security.txt, che dicono dove vanno le segnalazioni e fino a quando quelle informazioni valgono. Il formato è stato pubblicato come RFC 9116 nel 2022. Scanner, piattaforme di bug bounty e agenzie nazionali di sicurezza leggono il file in automatico quando hanno qualcosa da comunicare.
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policyCosa legge questo controllo
Il nostro server richiede https://your-host/.well-known/security.txt, poi il vecchio indirizzo /security.txt nella radice se il primo non restituisce nulla. I reindirizzamenti vengono seguiti. Una risposta con stato 200 che si rivela una pagina HTML conta come file assente, perché molti siti rispondono a ogni indirizzo sconosciuto con la loro home page.
Quando il file c’è, lo giudichiamo su tre aspetti.
| Parte | Cosa deve essere vero |
|---|---|
| Come viene servito | All’indirizzo /.well-known/, in HTTPS, con Content-Type: text/plain. Un reindirizzamento verso un altro dominio viene segnalato. |
Contact | Almeno uno, ognuno sotto forma di URI: mailto:, https:// o tel:. Un indirizzo e-mail nudo senza mailto: è un errore. |
Expires | Esattamente uno, scritto come timestamp completo, per esempio 2027-01-31T00:00:00.000Z, nel futuro. Scaduto è un errore; meno di 30 giorni rimasti o più di un anno avanti è un avviso. |
| Campi facoltativi | Encryption, Acknowledgments, Policy, Hiring e CSAF devono essere indirizzi https://. Preferred-Languages compare una sola volta e contiene codici di lingua. Canonical deve includere l’indirizzo da cui il file è stato letto. |
I nomi di campo fuori dallo standard vengono elencati senza penalità, perché le estensioni sono ammesse. Il controllo dice anche se il testo è racchiuso in una firma OpenPGP in chiaro. Non verifica quella firma.
Gli errori che vediamo più spesso
- Una data scaduta
- Qualcuno ha scritto il file una volta e poi se n’è dimenticato. La RFC 9116 dice che un file scaduto non andrebbe usato, quindi chi segnala torna a tirare a indovinare. Rinnovarlo richiede due minuti: conferma i contatti, sposta la data, pubblica.
- Nessun
Expires - I file scritti prima del 2022 seguivano una bozza in cui il campo era facoltativo. Adesso è obbligatorio.
Contact: security@example.com- Il valore deve essere un URI. Scrivi
mailto:security@example.com. - Il file solo nella radice
/security.txtè un ripiego. Metti il file in/.well-known/e reindirizza lì il vecchio indirizzo.- Un
Canonicalcopiato da un altro sito - Se il campo c’è e non elenca l’indirizzo da cui il file viene servito, il file si contraddice da solo.
Pubblicarne uno che riesci a tenere aggiornato
Comincia decidendo chi legge la casella. Un indirizzo condiviso come security@ che arriva a due persone è meglio di una persona sola. Poi usa il generatore di questa pagina. Aggiunge mailto: dove serve, formatta la data e la imposta già a un anno di distanza.
Carica il risultato in una cartella chiamata .well-known nella radice del sito. La maggior parte dei server invia i file .txt come text/plain senza bisogno di dirlo. Se il tuo nasconde le cartelle che cominciano con un punto, aggiungi un’eccezione. In nginx:
location = /.well-known/security.txt {
default_type text/plain;
charset utf-8;
}La firma è facoltativa. Con GnuPG, gpg --clearsign security.txt produce una versione firmata da pubblicare al suo posto. Inserisci una riga Canonical prima di firmare, così la firma copre anche l’indirizzo.
Questa pagina legge un host, una volta. Non può sapere se qualcuno risponde all’indirizzo di contatto, se la policy collegata esiste o se la firma è autentica. Un file assente non è una falla di sicurezza e qui non abbassa nessun voto.
Domande frequenti
Un security.txt mancante è una vulnerabilità?
No. Il file è una cortesia che facilita le segnalazioni, e da solo non protegge nulla. Alcuni scanner automatici elencano la sua assenza come problema di bassa gravità. Prendila come un suggerimento.
Dove va esattamente security.txt?
In https://your-domain/.well-known/security.txt, servito in HTTPS come testo semplice. Ogni host è separato, quindi un file su example.com non copre app.example.com.
Pubblicare un indirizzo di contatto attirerà spam o false segnalazioni di bug?
Aspettati qualche segnalazione automatica di poco valore, spesso con richiesta di ricompensa. Una breve pagina di policy che dice cosa rientra nel perimetro e se paghi bounty filtra la maggior parte di queste. Aiuta anche far puntare Contact a un modulo web invece che a una casella.
Quanto deve essere lontana la data Expires?
Meno di un anno avanti, come raccomanda la RFC. La data è una promessa che i contatti erano corretti all’ultima revisione del file, ed è per questo che dovrebbe essere breve. Imposta un promemoria un mese prima della scadenza.
Devo firmare il file con PGP?
No. Una firma aiuta chi legge a confermare che il file non è stato alterato su un server compromesso, e funziona solo se la tua chiave pubblica si può ottenere altrove. Moltissimi file validi non sono firmati.
Che differenza c’è tra security.txt e robots.txt?
Entrambi sono file di testo semplice a un indirizzo noto, letti da software. robots.txt dice ai crawler quali pagine lasciare stare. security.txt dice a chi ha trovato un problema di sicurezza come contattarti. Nessuno dei due impone nulla.