Aller au contenu
TextArray1.41.0
Tout en local

Validateur security.txt

Vérifiez un fichier security.txt contre RFC 9116 et listez ce qui est manquant, invalide ou obsolète.

Entrée
Sortie
Outils connexes
Robots.txt testernouveauOutils de développement
Générateur de fichiers humains.txtOutils de développement
Vérificateur SPF et DMARCnouveauOutils de développement
différence de clé i18nOutils de développement
Convertisseur TOML en JSONOutils de développement
SQL vers JSONOutils de développement
Validateur security.txt
Collez le contenu d'un fichier security.txt — celui qui est censé résider à /.well-known/security.txt — et cet outil le vérifie contre RFC 9116, la norme qui définit le format. Il signale les champs obligatoires manquants, les valeurs qui ne s'analysent pas, et les noms de champs qui sont obsolètes ou non reconnus, chacun lié à la ligne d'où il provient.
RFC 9116 nécessite au moins une ligne « Contact » et exactement une ligne « Expires » ; les deux sont vérifiées par défaut, ainsi que la date « Expires » elle-même — elle doit être un horodatage ISO 8601 complet avec un fuseau horaire, et l'outil avertit lorsque cette date a déjà passé. Encryption, Policy, Hiring, Canonical et Acknowledgments sont censés contenir une URI, donc l'outil signale un domaine nu ou une adresse électronique sans schéma. Il capture également l'orthographe britannique obsolète « Acknowledgements » (RFC 9116 utilise « Acknowledgments »), les champs abandonnés dans les brouillons antérieurs tels que « Disclosure », les noms de champs saisis dans la mauvaise casse, les lignes « Expires » ou « Preferred-Languages » en double, et les champs qui sortent de l'ordre de lecture conventionnel. N'importe lequel de ces contrôles peut être désactivé individuellement.
Basculez la sortie entre une liste ligne par ligne de résultats et un fichier corrigé : la version corrigée regroupe les champs reconnus dans l'ordre conventionnel, réduit les champs singuliers en double à la première occurrence, corrige les noms de champs obsolètes, et conserve tout ce qu'il ne reconnaît pas plutôt que de le supprimer. Les lignes sans une forme valide « Champ : valeur » sont signalées au lieu d'être devinées, et un « Contact » ou « Expires » manquant est noté avec un commentaire plutôt que d'être inventé.
Tout s'exécute localement dans votre navigateur — le fichier que vous collez, qui contient souvent une adresse de contact de sécurité réelle et non publiée, n'est jamais téléchargé nulle part. Copiez le résultat, téléchargez-le en tant que fichier .txt prêt à publier, ou renvoyez-le à l'entrée pour vérifier une autre version.
FAQ
Que demande réellement RFC 9116 ?
Au minimum, un champ « Contact » et exactement un champ « Expires » avec une date-heure valide selon RFC 3339. Tout le reste — Encryption, Canonical, Preferred-Languages, Acknowledgments, Hiring et Policy — est facultatif.
Pourquoi ma date « Expires » est-elle signalée comme invalide ?
RFC 9116 nécessite une date-heure complète avec un fuseau horaire, comme 2027-01-01T00:00:00Z. Une date nue comme 2027-01-01, ou un format non ISO, ne satisfait pas la spécification même si elle ressemble à une date.
Que change le « Fichier corrigé » ?
Il regroupe les champs reconnus dans l'ordre de lecture conventionnel, conserve uniquement la première occurrence d'un champ qui doit être singulier (Expires, Preferred-Languages), et corrige l'orthographe obsolète « Acknowledgements » en « Acknowledgments ». Il n'invente jamais une valeur Contact ou Expires qui ne soit déjà dans votre fichier.
Récupère-t-il mon security.txt en direct depuis mon domaine ?
Non. Collez le contenu du fichier vous-même — l'outil ne fait jamais de requête réseau, il ne peut donc pas confirmer ce qui est réellement publié à /.well-known/security.txt sur votre site.
Mon fichier security.txt est-il téléchargé quelque part ?
Non. La validation s'exécute entièrement dans votre navigateur. Puisque ce fichier contient souvent une adresse de contact de sécurité réelle et non publiée, rien de ce que vous collez ne quitte jamais votre appareil.