Verificatore di security.txt

Come funziona questo controllo

Scanaris richiede /.well-known/security.txt, il percorso standard della RFC 9116, e se non lo trova prova /security.txt nella radice, la posizione storica. Considera il file presente solo se risponde 200 e contiene una riga che inizia con Contact:, l'unico campo obbligatorio insieme a Expires. Così esclude le single-page app che restituiscono il loro HTML per qualsiasi percorso. Se non lo trova, apre un rilievo di livello informativo: non toglie punti al tuo voto, perché non averlo non è una falla di sicurezza; è una buona pratica che ti manca.

A cosa serve

Quando qualcuno trova una falla nel tuo sito (un ricercatore, un utente curioso, un'altra azienda), deve sapere a chi dirlo. Senza un canale chiaro, di solito non lo dice, oppure lo pubblica, oppure scrive al modulo di contatto generico che nessuno legge. security.txt è un file di testo in un percorso noto dove dici "scrivimi qui, in questa lingua, e questa è la mia policy". Lo leggono persone e strumenti, e sempre più programmi di bug bounty e assicuratori lo danno per scontato. Protegge anche te: chiarisce che accetti segnalazioni responsabili e a quali condizioni.

Come crearlo

Un file minimo valido:

Contact: mailto:security@tuodominio.it
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: it, en
Canonical: https://tuodominio.it/.well-known/security.txt

• Contact (obbligatorio): un mailto:, un URL di modulo o un tel:. Puoi metterne diversi, in ordine di preferenza. La casella deve esistere ed essere letta.
• Expires (obbligatorio): data in formato ISO 8601 oltre la quale il file non è più valido. La RFC consiglia meno di un anno: mettiti un promemoria per rinnovarlo.
• Preferred-Languages, Policy (URL della tua policy di divulgazione), Encryption (la tua chiave PGP) e Acknowledgments (pagina dei ringraziamenti) sono facoltativi.
• Canonical indica l'URL ufficiale del file; utile se firmi il file con PGP così che nessuno possa pubblicarne uno falso.

Dove metterlo

• Nuxt, Next.js, Vite, Astro: crea public/.well-known/security.txt; viene servito così com'è. Controlla che il .gitignore non ignori le cartelle che iniziano con un punto.
• Vercel e Netlify: lo stesso, dentro la cartella pubblica del progetto.
• nginx o Apache: un file in /.well-known/security.txt della directory servita; se la tua applicazione cattura tutte le rotte, aggiungi un'eccezione per /.well-known/.
• WordPress: carica il file via FTP in .well-known/ nella radice, oppure usa un plugin che lo generi.

Servilo come text/plain e in HTTPS. Se hai molti domini, ognuno deve avere il suo o reindirizzare a quello canonico.

Verifica che sia risolto

curl -si https://tuodominio.it/.well-known/security.txt | grep -iE "^(HTTP|content-type|contact|expires)"

Atteso: 200, tipo text/plain, una riga Contact: e una Expires: con data futura.

Domande frequenti

Riceverò più spam o e-mail di "cacciatori di taglie"?

Un po' di posta di bassa qualità arriverà; è il prezzo di essere raggiungibili. Un filtro semplice e una policy chiara (cosa conta come segnalazione valida, se paghi o no) riducono il rumore. Quello che ti risparmia è l'alternativa: scoprirlo su Twitter.

Posso indicare solo il modulo di contatto generale?

Puoi, ma è meglio una casella dedicata che qualcuno controlli. Se il modulo generale lo legge il marketing, una segnalazione di vulnerabilità può impiegare settimane ad arrivare alla persona giusta.

Perché non penalizza il voto?

Perché misura la preparazione, non l'esposizione. Gli altri controlli di sicurezza, quelli che pesano davvero, sono nella checklist di sicurezza prima del lancio.