Generatore e verificatore di security.txt
Crea un security.txt valido secondo RFC 9116, così chi scopre una falla sa come contattarti, oppure incolla un file esistente per vedere cosa non va. Fa parte della preparazione al regolamento UE sulla ciberresilienza (CRA).
Funziona interamente nel tuo browser
Genera un security.txt
Verifica un security.txt
Controlla il testo solo rispetto a RFC 9116. Non scarica il tuo sito (nulla di ciò che scrivi lascia questa pagina, quindi incolla il file), non verifica una firma OpenPGP e non prova che un indirizzo funzioni. È un modello, non una consulenza legale.
Come creare e verificare un security.txt
- Inserisci almeno un Contact (un indirizzo e-mail, un numero di telefono o una pagina https://) e controlla la data di Expires. Compila i campi facoltativi che ti servono, come Policy e Preferred-Languages.
- Copia il file o scaricalo e pubblicalo in
/.well-known/security.txtsul tuo dominio, via HTTPS e come testo semplice. - Per verificare un file esistente, incolla il suo testo nel verificatore. Correggi gli errori, poi guarda gli avvisi. Aggiungi l'indirizzo da cui lo pubblichi per controllare il campo Canonical.
- Segna in calendario un promemoria per rinnovare Expires prima che scada.
A cosa serve un security.txt
Quando un ricercatore, un cliente o un CERT trova una debolezza nel tuo software, il primo problema è a chi dirlo. Un security.txt è un piccolo file di testo a un indirizzo fisso, /.well-known/security.txt, che risponde a questa domanda: un contatto, una data di scadenza e, facoltativamente, un link alla tua policy di divulgazione e a una chiave pubblica. RFC 9116 ne definisce il formato e molti scanner, piattaforme di bug bounty e CERT nazionali cercano questo file prima di qualsiasi altra cosa.
Per un fornitore di software nell'UE aiuta anche a rispettare gli obblighi del regolamento (UE) 2024/2847 sulla ciberresilienza (Cyber Resilience Act, CRA): l'allegato I si aspetta un modo pubblicato per segnalare dall'esterno le vulnerabilità e un processo per gestirle. Il regolamento non nomina questo formato, ma è il modo usuale di pubblicare il contatto. La guida alla segnalazione per i piccoli fornitori descrive il resto della configurazione, compreso il termine di 24 ore.
I campi
Contact ed Expires sono obbligatori. Contact può comparire più volte e deve essere un URI: mailto:, tel: o https:. Expires compare una sola volta, come data e ora, per esempio 2027-12-31T23:59:59Z, e RFC 9116 chiede una scadenza entro un anno. Encryption, Acknowledgments, Policy, Hiring e Canonical sono link facoltativi, e ogni indirizzo web deve usare https. Preferred-Languages compare una sola volta ed elenca codici lingua. I campi che l'RFC non definisce vengono ignorati da chi legge, perciò il verificatore li segnala come avvisi: di solito sono refusi.
Consigli
- Usa una casella letta da più persone, non l'indirizzo di una sola, e provala scrivendole.
- Scrivi una policy di divulgazione delle vulnerabilità e collegala con il campo Policy.
- Conosci le scadenze prima che arrivi una segnalazione: l'orologio CRA delle 24 ore trasforma il momento in cui sei venuto a conoscenza di un fatto in scadenze con data.
Domande frequenti
Il regolamento sulla ciberresilienza richiede un security.txt?
No. Il regolamento si aspetta che i fabbricanti abbiano una politica di divulgazione coordinata delle vulnerabilità e un modo pubblicato per segnalarle. Il file security.txt è il modo più diffuso per pubblicare quel contatto e gli esperti lo raccomandano, ma il regolamento non nomina questo formato. Vedi la guida per i piccoli fornitori.
Dove devo mettere esattamente il file?
In https://tuo-dominio/.well-known/security.txt, servito via HTTPS con tipo di contenuto text/plain; charset=utf-8. RFC 9116 ammette anche una copia in /security.txt per le configurazioni più vecchie. Pubblicalo su ogni dominio o sottodominio che vuoi coprire.
Quanto lontano deve essere Expires?
RFC 9116 dice che dovrebbe cadere a meno di un anno da oggi, così chi legge può fidarsi che i dati di contatto siano aggiornati. Il generatore propone una data poco inferiore a un anno. Quando la data passa, i lettori devono ignorare il file: rinnovalo per tempo.
Devo firmare il file con PGP?
No, la firma è facoltativa ma consigliata. Un file firmato è un messaggio OpenPGP con firma in chiaro, creato con gpg --clearsign security.txt. Il verificatore riconosce il formato firmato e ne controlla la struttura, ma non può verificare la firma: per questo usa gpg --verify.
Perché il verificatore non scarica il mio sito?
Per tutelare la tua privacy: la pagina funziona interamente nel tuo browser e non fa richieste ad altri siti. Apri il file in una scheda del browser, copia il testo e incollalo qui. Così verifichi anche ciò che i visitatori ricevono davvero.
A cosa serve il campo Canonical?
Elenca gli indirizzi da cui il file deve essere pubblicato, così chi lo legge può confermare che un file trovato a un indirizzo gli appartiene davvero. Se inserisci l'indirizzo da cui pubblichi il file, il verificatore controlla che una delle righe Canonical coincida.