Verifica del file security.txt
Incollate il contenuto del file security.txt, definito dalla norma RFC 9116, per rilevarne gli errori di sintassi. Verifica la presenza e il formato dei campi obbligatori, come il contatto e la scadenza, e permette di accertare la corretta collocazione in /.well-known/security.txt.
Validare il formato di un security.txt
Un security.txt è il file di testo con cui un sito indica a chi abbia trovato una vulnerabilità a chi rivolgersi, e il suo formato è stabilito dalla RFC 9116. Incollatene il contenuto e questo strumento controlla la sintassi, accertando che campi obbligatori come Contact ed Expires siano presenti e che i loro valori assumano la forma dovuta.
Ciò che qui si tende a trascurare è il trattamento di Expires. Non solo è un campo obbligatorio, ma un file il cui istante dichiarato è trascorso va considerato obsoleto, e il suo contenuto non dovrebbe più essere usato. Pubblicatelo e disinteressatevene, e dopo qualche anno sarà ancora lì ma inerte, sicché conviene gestirlo insieme a un piano di rinnovo. Anche la sua collocazione è fissata: gli spetta /.well-known/security.txt. Quando il file è firmato, il campo Canonical dichiara l'indirizzo che fa fede, affinché chi legge possa accertarsi che nessuno vi abbia messo mano.
Come si usa
- Incollate il contenuto del vostro security.txt Inserite l'intero file così com'è.
- Provate prima gli esempi Sono forniti sia un esempio valido sia uno che contiene errori.
- Leggete i punti sollevati Vengono riferiti sia i campi obbligatori assenti sia i valori mal formati.
-
Controllate l'istante indicato in
ExpiresAccertate che non cada nel passato e stabilite in anticipo quando lo rinnoverete.
Consigli per sfruttarlo al meglio
- La specifica ufficiale prevede la collocazione in
/.well-known/security.txt. Per compatibilità conviene collocarne una copia anche in/security.txt, cioè nella radice del sito. - Scrivete il contatto come identificativo di risorsa completo di schema, per esempio mailto:, https: oppure tel:. Un semplice indirizzo di posta in chiaro non è conforme alla norma e può non essere riconosciuto dagli strumenti di analisi automatica.
- Impostate la scadenza a non più di un anno e prorogatela a ogni aggiornamento: un file scaduto rischia di essere considerato un contatto ormai abbandonato.
- La verifica avviene interamente nel navigatore e quanto inserite non viene trasmesso all'esterno: potete incollare con serenità anche un file non ancora pubblicato.
Quando torna utile
Nel rendere esplicito il vostro contatto di sicurezza
Chi trova qualcosa non dovrà andare in cerca di un indirizzo, e la segnalazione vi giungerà assai più facilmente.
Nel verificare ciò che avete pubblicato
Un file mal formato non ne lascia trapelare nulla all'esterno: solo una validazione lo rivela.
Nel prevenire la scadenza
Potete controllare di tanto in tanto che Expires non sia trascorso.
Nel tenere uno standard nell'organizzazione
Quando si conducono più siti insieme, potete accertare che tutti seguano lo stesso formato.
Termini di security.txt
- Contact
- Campo obbligatorio che dà un modo per mettersi in contatto: un indirizzo di posta elettronica, un numero di telefono o l'indirizzo di un modulo di segnalazione.
- Expires
- Campo obbligatorio; trascorso l'istante dichiarato, il file va considerato obsoleto e non dovrebbe più essere usato.
- Encryption
- Indica una chiave pubblica con cui una segnalazione può essere cifrata.
- Policy
- L'indirizzo di una pagina che espone la politica sulla divulgazione delle vulnerabilità.
- Canonical
- L'indirizzo che fa fede presso cui questo file dovrebbe risiedere. È ciò a cui una firma viene raffrontata.
- Preferred-Languages
- Dichiara le lingue in cui le segnalazioni possono essere ricevute, separate da virgole come in
en, ja.
Domande frequenti
https://example.com/.well-known/security.txt. Poiché molte realizzazioni consultano ancora la vecchia posizione https://example.com/security.txt, per compatibilità si raccomanda di collocarlo in entrambe.mailto:[email protected]. Senza schema gli strumenti di analisi automatica possono non riconoscerlo.
A proposito — perché è nato security.txt: il primo sportello che i programmi di ricompensa non bastavano a offrire
Il file security.txt fu proposto nel 2017 dai ricercatori di sicurezza Ed Overflow e Kagan Baytas. All'epoca capitava spesso che chi individuava una vulnerabilità non trovasse un recapito adatto per segnalarla all'azienda e dovesse ripiegare sullo sportello generico o su un messaggio privato in una rete sociale. Non era raro che la segnalazione impiegasse molto tempo a raggiungere chi di dovere, o che restasse del tutto inascoltata.
La proposta fu portata all'ente che cura gli standard di Internet e, dopo un lungo dibattito e numerose revisioni, è diventata nel 2022 la norma ufficiale RFC 9116. Il meccanismo è semplicissimo: basta che chi gestisce un sito pubblichi un file di testo in /.well-known/security.txt perché chi fa ricerca possa sapere meccanicamente a chi rivolgersi, in quale lingua e con quali regole.
Molte grandi aziende tecnologiche lo hanno adottato e non è raro che nei campi dedicati alla politica di divulgazione rimandino al proprio programma di ricompensa per la scoperta di vulnerabilità. Il file svolge insomma il ruolo di primo sportello, raggiungendo anche i ricercatori che non passano dalle piattaforme dedicate a quei programmi.
Come sviluppo della norma si diffonde anche l'estensione che, con un campo apposito, rimanda al quadro comune per gli avvisi di sicurezza, lo standard per lo scambio delle informazioni sulle vulnerabilità. Il file security.txt non è dunque un semplice elenco di recapiti, ma continua a evolvere come porta d'accesso all'intero assetto di sicurezza di un'organizzazione.