Contenuto informativo basato su fonti istituzionali. L’applicazione concreta richiede una valutazione del contesto, del rischio e della normativa vigente.

Pubblicare il file nella posizione e nel formato corretti

Per un servizio web RFC 9116 richiede il percorso /.well-known/security.txt. La risorsa deve essere servita in HTTPS come text/plain con charset UTF-8. Una copia al livello radice può esistere per compatibilità, ma deve rimandare alla posizione well-known e non creare versioni divergenti.

Contact è obbligatorio e può indicare email, telefono o pagina HTTPS. Expires è obbligatorio, compare una sola volta e dichiara quando il contenuto diventa obsoleto; la RFC raccomanda una data inferiore a un anno nel futuro. Canonical consente di dichiarare l’URI autorevole e aiuta a riconoscere copie alterate.

  • Contact monitorato da persone incaricate
  • Expires inserito nel calendario operativo
  • Canonical uguale all’URL effettivamente pubblicato
  • Preferred-Languages per le lingue gestibili
  • Policy ed Encryption solo se realmente mantenute

Definire perimetro e aspettative nella disclosure policy

Il file si applica al dominio o indirizzo dal quale viene recuperato, non automaticamente a tutti i sottodomini. Una policy collegata dovrebbe indicare sistemi inclusi ed esclusi, tipi di test ammessi, dati da non accedere, canale di comunicazione, tempi indicativi e modalità di coordinamento della divulgazione.

La presenza di security.txt non concede di per sé il permesso di eseguire test. Allo stesso modo, non è il canale ordinario per notificare un incidente operativo o una violazione di dati personali. Questi confini devono essere espliciti per ridurre incomprensioni e instradare correttamente le comunicazioni.

  • Asset inclusi ed esclusi nominati chiaramente
  • Regole per automazione, social engineering e disponibilità
  • Istruzioni per prove e dati personali
  • Divieto di estorsione e richieste improprie
  • Canali separati per incidenti, privacy e supporto

Preparare triage, risposta e conservazione

Una casella pubblicata attirerà anche spam e risultati di scanner senza analisi. Il processo interno assegna un proprietario, registra ricezione, asset, riproducibilità, severità, stato, comunicazioni e decisione. Un messaggio automatico può confermare la ricezione senza promettere tempi o riconoscimenti non sostenibili.

Le evidenze possono contenere credenziali, dati personali o dettagli sfruttabili. Accesso, retention, condivisione con fornitori e cifratura vanno governati. Se la segnalazione riguarda un servizio di terzi, l’organizzazione mantiene il coordinamento e non inoltra indiscriminatamente informazioni sensibili.

  • Numero di pratica e conferma di ricezione
  • Verifica tecnica in ambiente controllato
  • Classificazione di impatto e urgenza
  • Piano di correzione e nuova verifica
  • Comunicazione finale e lezione appresa

Mantenere il canale verificabile nel tempo

Un file scaduto o una casella non presidiata può essere peggiore dell’assenza perché indirizza segnalazioni sensibili verso un canale inattivo. Expires deve quindi generare un’attività ricorrente; cambi di dominio, team, fornitore o chiave di cifratura richiedono aggiornamento anticipato.

Il controllo periodico verifica risoluzione DNS, certificato, redirect, tipo MIME, contenuto e consegna della casella. È utile eseguire un test completo con una segnalazione simulata e misurare presa in carico, escalation e chiusura, senza pubblicare riconoscimenti o bug bounty non realmente gestiti.

Domande frequenti

Quali campi sono obbligatori in security.txt?+

RFC 9116 richiede almeno un campo Contact e un campo Expires. Per i servizi web richiede inoltre la pubblicazione HTTPS in /.well-known/security.txt con tipo text/plain e charset UTF-8.

Security.txt autorizza i penetration test?+

No. La sua presenza facilita la segnalazione, ma non concede automaticamente il permesso di testare. Le attività consentite devono essere descritte in una vulnerability disclosure policy esplicita.

Security.txt sostituisce il processo di incident response?+

No. È pensato per la disclosure di vulnerabilità. Incidenti operativi, violazioni di dati e richieste di supporto richiedono canali e procedure specifici.

Fonti istituzionali

Approfondisci nel sito