Générateur et validateur de security.txt

Qu'est-ce qu'un security.txt ?

Un fichier security.txt est un court fichier texte qui indique à quiconque a trouvé une faille sur votre site où la signaler. Avant lui, le chercheur qui remarquait quelque chose devait deviner : tenter security@ en espérant que la boîte soit lue, fouiller une page de contact, ou renoncer et se taire. Le fichier remplace cette devinette par un emplacement fixe et une poignée de champs nommés, et il est devenu une norme — le RFC 9116 — en avril 2022.

Le format est volontairement dépouillé. Chaque ligne est un nom de champ, deux-points, une espace et une valeur, et les lignes commençant par # sont des commentaires. Deux champs seulement sont obligatoires : Contact, qui dit où envoyer les signalements, et Expires, qui dit à partir de quand l'information cesse d'être fiable. Tout le reste — le lien vers votre politique, une clé de chiffrement, une page de remerciements, les langues que vous lisez — est facultatif.

Il est aussi assez petit pour être fautif sans que personne s'en aperçoive, et c'est à cela que sert le vérificateur de cette page. Parmi les fichiers publiés par les 500 domaines les plus fréquentés du web, moins de la moitié respectent aujourd'hui la norme selon laquelle ils sont écrits.

Comment l'utiliser

1. Saisissez votre contact et l'expiration. Contact doit être un URI : une adresse e-mail demande donc le préfixe mailto: et un numéro de téléphone tel:. Le champ d'expiration est prérempli à un an, le maximum que recommande la norme.
2. Ajoutez les champs facultatifs qu'il vous faut. Un lien vers votre politique, une clé OpenPGP, une page de remerciements, les langues que vous lisez. Contact et la plupart des autres peuvent être répétés ; Expires et Preferred-Languages, non.
3. Publiez-le, ou vérifiez celui que vous servez déjà. Le fichier se place à /.well-known/security.txt en HTTPS. Passez à l'onglet de vérification pour coller un fichier existant et voir chaque problème avec son numéro de ligne.

Ce que les fichiers publiés ratent

Les chiffres viennent d'une interrogation des deux emplacements possibles pour les 500 domaines les plus fréquentés du web selon le classement Tranco, puis du passage de tout ce qui a répondu dans le vérificateur même que propose cette page. 115 de ces domaines publient quelque chose ; 45 d'entre eux, soit 39,1 %, ne comportent aucune erreur.

Le défaut le plus répandu, et de loin, est l'absence du champ Expires : 48 fichiers, 41,7 % de tout ce qui est publié. Ce n'est pas une règle obscure — Expires est l'un des deux seuls champs obligatoires — et l'explication est nette. Expires n'existait pas dans les premiers brouillons à partir desquels tout le monde a implémenté ; il a été ajouté en chemin vers le statut de RFC. Le problème le plus fréquent est donc le champ que la norme a ajouté en dernier, dans des fichiers qui étaient corrects au moment où on les a écrits.

L'expiration échoue d'une seconde façon : 11 de ces fichiers déclarent être déjà périmés, ce qui, selon la définition même de la norme, signifie que leur contenu ne devrait plus servir. Celui d'un réseau social très connu portait une date de janvier 2024. Treize autres repoussent la date si loin qu'elle ne pourra jamais utilement échoir : celui d'un grand moteur de recherche indique 2030, presque quatre ans, contre une recommandation de rester sous un an.

Quatorze fichiers donnent un Contact qui n'est pas un URI. C'est le piège que le format tend à qui écrit ce qui semble évident : une adresse nue comme psirt@example.com se lit très bien et reste invalide, parce que le champ est spécifié comme un URI et réclame mailto: devant. Un éditeur de logiciels bien connu publie un contact https correct, puis une adresse nue à la ligne suivante. S'il vous en faut un, notre générateur de liens mailto écrit l'ensemble.

Seize fichiers contiennent une ligne qui n'est pas un champ, le plus souvent un titre comportant des espaces, et quelques-uns sont de la prose pure : un paragraphe expliquant comment signaler une faille, publié à l'endroit où l'on attendait un fichier lisible par une machine. Six n'ont aucun champ Contact, ayant inventé leur propre nom pour lui.

Où le fichier se place, et ce qui n'est pas couvert

La norme est précise sur l'emplacement : le fichier doit se trouver à /.well-known/security.txt. Une copie à la racine du site n'est admise que par compatibilité héritée, et lorsque les deux existent, c'est celle de well-known qui l'emporte. Vingt-six des domaines mesurés le servent aux deux endroits, ce qui convient ; huit ne le servent qu'à la racine, si bien qu'un outil conforme peut n'y regarder jamais.

La portée du fichier est plus étroite que presque tout le monde ne le suppose. Il ne vaut que pour le domaine ou l'adresse IP exacts d'où il a été récupéré, ni pour les sous-domaines, ni pour le domaine parent. Un fichier sur example.com ne dit rien de nimporte.example.com, et chaque hôte qui en a besoin a besoin du sien.

Les champs inconnus ne sont pas des erreurs. La norme ordonne au lecteur d'ignorer tout champ qu'il ne reconnaît pas ; le vérificateur signale donc un nom non enregistré comme une remarque et non comme un problème. C'est un choix délibéré de la norme, et un validateur qui le marquerait comme invalide contredirait le document même au regard duquel il valide.

Deux des champs présentés sur cette page ne figurent nulle part dans le RFC 9116. Le registre est tenu par l'IANA et il s'est étoffé depuis la publication : CSAF, qui pointe vers un flux d'avis lisible par une machine et qui est le seul champ du format dont le contrôle des modifications n'appartient pas à l'IETF, et Bug-Bounty, le seul dont la valeur n'est ni un URI, ni une date, ni une étiquette de langue, mais simplement True ou False.

Ce que cette page ne fait pas, c'est vérifier les signatures. Un fichier peut être enveloppé dans une signature OpenPGP, et dix-huit des fichiers mesurés le sont ; les champs qu'elle contient sont vérifiés normalement, mais confirmer une signature supposerait de manipuler des clés, ce qui est un autre métier que lire un format texte.

Pourquoi est-ce gratuit ?

Tout cela n'est qu'un format texte. Générer un fichier revient à concaténer des chaînes et le vérifier à écrire un analyseur, deux choses qui tournent dans votre navigateur : il n'y a donc pas de serveur à payer ni de compte à créer.

Rien de ce que vous saisissez n'est envoyé, conservé ni journalisé. Cela compte davantage ici que sur la plupart des pages : un fichier de contact de sécurité est public par vocation, mais le brouillon que vous êtes en train d'écrire ne l'est pas, pas plus que le fichier que vous avez collé pour savoir ce qui cloche dedans.