Comment fonctionne cette vérification
Scanaris demande /.well-known/security.txt, l'emplacement standard défini par la RFC 9116, et s'il ne le trouve pas, essaie /security.txt à la racine, l'ancien emplacement. Il ne considère le fichier comme présent que s'il répond 200 et contient une ligne commençant par Contact:, le seul champ obligatoire avec Expires. Ça écarte les applications monopages qui renvoient leur HTML pour n'importe quel chemin. S'il ne le trouve pas, il ouvre un constat de niveau informatif : ça ne retire aucun point à ta note, parce que ne pas l'avoir n'est pas une faille de sécurité ; c'est une bonne pratique qui te manque.
À quoi ça sert
Quand quelqu'un trouve une faille sur ton site (un chercheur, un utilisateur curieux, une autre entreprise), il doit savoir à qui le dire. Sans canal clair, le plus souvent il ne dit rien, ou il publie, ou il écrit au formulaire de contact générique que personne ne lit. security.txt est un fichier texte à un chemin connu où tu dis « écris-moi ici, dans cette langue, et voici ma politique ». Il est lu par des personnes et des outils, et de plus en plus de programmes de récompense et d'assureurs le considèrent comme acquis. Il te protège aussi : il établit que tu acceptes les signalements responsables et à quelles conditions.
Comment le créer
Un fichier minimal valide :
Contact: mailto:security@tondomaine.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: fr, en
Canonical: https://tondomaine.com/.well-known/security.txt- Contact (obligatoire) : un
mailto:, une URL de formulaire ou untel:. Tu peux en mettre plusieurs, par ordre de préférence. La boîte doit exister et être lue. - Expires (obligatoire) : date au format ISO 8601 à partir de laquelle le fichier n'est plus valable. La RFC recommande moins d'un an : mets-toi un rappel pour le renouveler.
- Preferred-Languages, Policy (URL de ta politique de divulgation), Encryption (ta clé PGP) et Acknowledgments (page de remerciements) sont facultatifs.
- Canonical indique l'URL officielle du fichier ; utile si tu signes le fichier avec PGP pour que personne ne puisse en publier un faux.
Où le placer
- Nuxt, Next.js, Vite, Astro : crée
public/.well-known/security.txt; il est servi tel quel. Vérifie que ton.gitignoren'ignore pas les dossiers commençant par un point. - Vercel et Netlify : pareil, dans le dossier public du projet.
- nginx ou Apache : un fichier à
/.well-known/security.txtdu répertoire servi ; si ton application capture toutes les routes, ajoute une exception pour/.well-known/. - WordPress : envoie le fichier par FTP dans
.well-known/à la racine, ou utilise un plugin qui le génère.
Sers-le en text/plain et en HTTPS. Si tu as plusieurs domaines, chacun doit avoir le sien ou rediriger vers le canonique.
Vérifie que c'est corrigé
curl -si https://tondomaine.com/.well-known/security.txt | grep -iE "^(HTTP|content-type|contact|expires)"Attendu : 200, type text/plain, une ligne Contact: et une ligne Expires: avec une date future.
Questions fréquentes
Vais-je recevoir plus de spam ou de courriers de « chasseurs de primes » ?
Un peu de courrier de faible qualité arrivera ; c'est le prix d'être joignable. Un filtre simple et une politique claire (ce qui compte comme signalement valable, si tu paies ou non) réduisent le bruit. Ce que ça t'épargne, c'est l'alternative : l'apprendre sur Twitter.
Puis-je mettre seulement le formulaire de contact général ?
Tu peux, mais une boîte dédiée que quelqu'un relève est préférable. Si le formulaire général est lu par le marketing, un signalement de vulnérabilité peut mettre des semaines à atteindre la bonne personne.
Pourquoi ça ne pénalise pas la note ?
Parce que ça mesure la préparation, pas l'exposition. Les autres vérifications de sécurité, celles qui pèsent, sont dans la checklist de sécurité avant de lancer.