Come pubblicare il contatto di sicurezza del tuo sito

Chi trova una falla sul tuo sito cerca un indirizzo a cui scriverti. L'RFC 9116, aprile 2022, documento informativo dell'IETF, definisce un file di testo, per convenzione security.txt, da mettere in un percorso noto. Il 4 novembre 2026 ho letto il testo su rfc-editor.org e la pagina delle errata. Non ho pubblicato il file su un sito in produzione e non ho firmato una chiave.

Il documento è RFC 9116. Le errata stanno su errata.rfc-editor.org. Il file va letto in HTTPS: il controllo del certificato è un altro pezzo, Che cosa controllare sul lucchetto del tuo sito.

Dove il browser, e il ricercatore, vanno a leggere

Per un servizio web l'organizzazione deve mettere il file sotto il percorso /.well-known/, per esempio https://example.com/.well-known/security.txt. Il riferimento è l'RFC 8615. Per compatibilità con il passato, un file può stare anche nella radice del sito, oppure fare un redirect verso quello in /.well-known/. Se i due posti hanno entrambi un file, si usa quello in /.well-known/.

L'accesso deve usare HTTP 1.0 o una versione successiva, e lo schema https. Il Content-Type deve essere text/plain, con il parametro charset di default a utf-8. Il file si applica al dominio o all'indirizzo IP dell'URI con cui lo si è scaricato, non ai sottodomini e non al dominio padre. Può applicarsi anche a prodotti e servizi dell'organizzazione che lo pubblica. Un esempio nel testo: il file di example.com non copre subdomain.example.com, che ha il suo.

Un redirect può finire su un altro dominio. La sezione 5.2 chiede di annotare i redirect prima di fidarsi del contenuto.

I due campi che il testo rende obbligatori

Salvo diversa indicazione, i campi sono facoltativi. Due fanno eccezione. Contact deve esserci sempre. È il modo per segnalare una vulnerabilità: email, telefono o pagina. Il valore deve essere un URI. Per l'email si usa lo schema mailto, per il telefono tel. Se il valore è un URI web, deve cominciare con https://. Più righe Contact sono ammesse e vanno in ordine di preferenza: la prima è il canale preferito. Expires deve esserci sempre, una volta sola. È la data dopo la quale il file è da considerare vecchio e da non usare. Il formato è quello di RFC 3339. Il testo raccomanda una scadenza a meno di un anno.

L'esempio stampato in sezione 2.5.5 è Expires: 2021-12-31T18:37:07z. Quella data è un esempio del 2022, già passata: non è una scadenza da copiare. La zeta finale, nel testo pubblicato, è minuscola. L'erratum 7264, solo segnalato e non verificato al 4 novembre 2026, chiede la Z maiuscola di RFC 3339. Non tratto quella segnalazione come una correzione già accolta. Un file vero ha bisogno di una data futura, decisa da chi pubblica.

I nomi dei campi non distinguono maiuscole e minuscole. Ogni campo sta su una riga sola, con nome, due punti e valore. Una riga che comincia con # è un commento. La riga finisce con CRLF oppure solo con LF: lo dice la sezione 2.2. L'erratum 7743, tecnico e ancora solo segnalato, vede una tensione fra questa frase e la grammatica formale, che in un punto sembra accettare solo CRLF. Qui seguo la sezione 2.2, che ammette entrambi, e lascio la segnalazione nello stato in cui l'ho trovata.

Gli altri campi, e l'ordine dei contatti

Encryption non contiene la chiave. Contiene un URI da cui scaricarla, per esempio una pagina https, un record DNS OPENPGPKEY o un fingerprint openpgp4fpr. Chi legge deve decidere se fidarsi di quella chiave. La firma del file, raccomandata in OpenPGP cleartext, è un'altra cosa: la chiave di Encryption non va assunta come la chiave della firma. Canonical elenca gli URI canonici del file. Se l'URI da cui hai scaricato il file non compare in nessun Canonical, il contenuto non andrebbe considerato affidabile. Il Canonical di per sé non estende il file a tutti gli URI elencati: per quella fiducia il testo indica anche la firma.

Policy punta alla policy di disclosure. Acknowledgments punta a una pagina di ringraziamenti, con cautela su quanti dettagli della falla si pubblicano. Hiring punta alle posizioni di lavoro sulla sicurezza. Preferred-Languages elenca tag di lingua separati da virgole, una sola volta nel file, senza un ordine di priorità. Se il campo manca, il ricercatore può assumere l'inglese. Gli URI web di questi campi, quando sono web, devono cominciare con https://.

L'erratum verificato 6946, del 28 aprile 2022, è editoriale. Nella grammatica un commento rimandava alla sezione 3.5.3. La sezione giusta, quella che descrive l'ordine delle righe Contact, è la 2.5.3. Ho seguito la 2.5.3.

Che cosa il file non decide

La sezione 5.5 dice che la presenza del file può essere scambiata per un permesso a fare prove sul sito, e l'assenza per un divieto. Il testo chiede di non fare nessuna delle due letture. Il permesso, se c'è, sta nella policy o in un campo ulteriore. Un file con dati vecchi può essere peggio di nessun file: le segnalazioni finiscono al contatto sbagliato. La sezione 5.3 lo scrive in modo diretto. In un ambiente con più utenti, la sezione 5.6 consiglia di riservare il nome security.txt sia nella radice sia in /.well-known/, così un terzo non pubblica la pagina al posto tuo.

Un sito compromesso può riscrivere anche questo file o metterci un redirect. Canonical, firma e un controllo periodico sono le contromisure che la sezione 5.1 elenca. Non ho verificato la firma di un file reale.

La fotografia è una cassetta delle lettere in Nuova Zelanda, opera propria di sarang, pubblico dominio, data nel JPEG 10 dicembre 2012 alle 08:26. È una cassetta del 2012. Il file security.txt del sito resta un altro oggetto.