security.txt, robots.txt et endpoints well-known

1 Introduction

Tout site web publie quelques petits fichiers texte qui ne sont pas des pages. Ils s'adressent à des machines : navigateurs, systèmes mobiles, moteurs de recherche, et aux personnes qui cherchent des failles. Trois d'entre eux apparaissent dans la section Web & TLS d'un scan de domaine : security.txt, les endpoints /.well-known/ et robots.txt.

Leurs rôles n'ont rien à voir. security.txt indique au chercheur qui a trouvé une vulnérabilité sur votre site à qui la signaler. Les endpoints well-known relient votre domaine à vos applications mobiles et à votre fournisseur d'identité. robots.txt demande aux robots d'éviter certains chemins, et révèle souvent à tout le monde où se trouvent vos pages d'administration. Aucun des trois n'est difficile à bien configurer, et tous sont publics par conception.

2022

security.txt devient un standard (RFC 9116)

Champs obligatoires dans security.txt : Contact et Expires

Protection apportée par robots.txt : c'est une demande, pas un contrôle d'accès

2 Comment ça marche

Ces trois fichiers vivent à des adresses fixes : n'importe qui, ou n'importe quel outil, les trouve en une seule requête sans rien savoir de votre site. Le scan se contente de les récupérer en HTTPS, comme un visiteur, et de lire ce qu'ils disent.

security.txt

Dans /.well-known/security.txt : qui contacter pour une vulnérabilité, et jusqu'à quand cette information est valable.

/.well-known/

Un dossier réservé (RFC 8615) où les standards rangent les fichiers que d'autres logiciels s'attendent à trouver : liens d'applications, découverte de connexion, changement de mot de passe.

robots.txt

À la racine du site : des consignes de politesse pour les robots. Les robots sérieux les suivent, tout le monde peut les lire.

Publics, et c'est voulu

Rien de tout cela n'est une fuite en soi : ces fichiers existent pour être lus. Les questions que pose le scan sont ailleurs. Le contact sécurité est-il présent et encore valide ? Les fichiers well-known en disent-ils plus que nécessaire (builds internes, identités de test) ? robots.txt liste-t-il des chemins que vous préféreriez cacher ? C'est surtout de l'hygiène, mais un security.txt absent ou expiré peut signifier qu'un signalement de vulnérabilité ne vous parviendra jamais.

3 Analyse détaillée

security.txt : votre contact de divulgation de vulnérabilités

Quand quelqu'un trouve une faille sur votre site, il lui faut un moyen de vous prévenir. Sans contact publié, les signalements finissent dans une boîte générique, sur les réseaux sociaux, ou nulle part. La RFC 9116 règle ce problème avec un simple fichier texte servi en HTTPS. Un fichier minimal valide :

Contact: mailto:[email protected]
Expires: 2027-06-30T23:00:00.000Z
Policy: https://example.fr/politique-securite
Preferred-Languages: fr, en
Canonical: https://example.fr/.well-known/security.txt

Contact (obligatoire)

Une ou plusieurs lignes, chacune une URI : mailto:, https: (un formulaire ou une page de bug bounty) ou tel:. Préférez une boîte partagée que quelqu'un lit vraiment plutôt qu'une personne qui peut partir. Le scan signale un fichier sans Contact (medium) et un Contact qui n'est pas l'un de ces types d'URI (low).

Expires (obligatoire)

Une date au format RFC 3339. Passé cette date, le chercheur doit considérer le fichier comme périmé : un fichier expiré ne vaut guère mieux que pas de fichier, et le scan le classe medium. Un Expires absent ou illisible est low. La RFC recommande une date à moins d'un an, et le scan note (info) une date plus lointaine. Mettez un rappel de renouvellement dans votre agenda.

Policy et Encryption

Policy: renvoie vers votre politique de divulgation : ce que les chercheurs peuvent tester, votre délai de réponse, votre engagement à ne pas poursuivre. Encryption: renvoie vers une clé publique (OpenPGP) pour recevoir des signalements chiffrés. Les deux sont facultatifs et rendent les bons signalements plus probables.

Canonical et signature

Canonical: donne l'URL où le fichier est censé se trouver. S'il pointe ailleurs que l'endroit où il est servi, le scan le signale (low) : le fichier a peut-être été copié d'un autre site. Le fichier peut aussi porter une signature OpenPGP en clair, qui permet de vérifier qu'il n'a pas été modifié. Le scan affiche « PGP signed » quand il en voit une. La signature est recommandée, pas obligatoire.

Emplacement

L'emplacement standard est /.well-known/security.txt. Le scan regarde aussi l'ancien /security.txt et note (info) quand le fichier n'existe que là. L'absence totale de fichier est signalée en low.

Endpoints well-known : ce que votre domaine déclare

Le scan interroge cinq adresses standard et ne retient que les vraies réponses (un site qui renvoie sa page HTML pour n'importe quel chemin ne compte pas comme un fichier JSON) :

/.well-known/assetlinks.json

Android App Links : quels packages Android peuvent ouvrir vos liens. Le rapport liste les noms de packages.

/.well-known/apple-app-site-association

L'équivalent Apple (universal links). Le rapport liste les bundle IDs et les Team IDs Apple.

/.well-known/openid-configuration

Découverte OpenID Connect : votre fournisseur d'identité, son issuer et ses endpoints de connexion, de jetons et de clés.

/.well-known/nodeinfo et /.well-known/change-password

nodeinfo décrit un logiciel du fediverse (Mastodon et consorts). change-password doit rediriger vers votre page de changement de mot de passe, pour que les gestionnaires de mots de passe y envoient directement l'utilisateur.

Les constats ici sont uniquement info (identités d'applications mobiles déclarées, issuer OpenID annoncé) : ils ne coûtent rien au score. Ce qui compte, c'est le contenu. Ces fichiers sont souvent générés une fois puis oubliés, et ils peuvent nommer des builds internes ou de développement (com.example.android.staff, ...debug) ou de vieilles applications. N'y gardez que les applications publiées, et retirez celles qui ne le sont plus. Annoncer son fournisseur d'identité est normal, mais cela indique à un attaquant où se trouve votre connexion : vérifiez qu'elle impose le MFA et limite les tentatives.

robots.txt : ce n'est pas un contrôle de sécurité

robots.txt (standardisé par la RFC 9309 en 2022) demande aux robots de ne pas visiter certains chemins. Les moteurs de recherche le respectent. Les attaquants le lisent comme un plan :

User-agent: *
Disallow: /admin/
Disallow: /preprod-2024/
Disallow: /sauvegardes/
Disallow: /api/interne/

Une ligne Disallow est un panneau indicateur

Chacun de ces chemins est désormais connu de tous. Si /admin/ n'est protégé que par « personne ne connaît l'URL », il n'est pas protégé. La vraie protection, c'est une authentification, une liste d'IP autorisées ou un VPN, et le chemin n'a alors aucune raison de figurer dans robots.txt.

Disallow ne retire pas une page des moteurs de recherche

Une URL interdite peut quand même apparaître dans les résultats si d'autres sites pointent vers elle. Pour exclure une page publique de l'index, utilisez une balise ou un en-tête noindex.

Ce que le scan en fait

Le fichier brut est replié dans Web & TLS, et ses règles pour les robots d'IA alimentent le bloc politique d'exploration IA. Le scan ne juge pas vos lignes Disallow : ouvrez le fichier et relisez-les vous-même, cela prend une minute.

Un bon robots.txt est court : il écarte les robots des pages de résultats de recherche interne, des paniers et autres URL sans intérêt, et indique votre sitemap. Tout ce qui est sensible est protégé par le serveur, et absent du fichier.

Vérifiez votre domaine sur mlab.sh

Un scan de domaine contrôle votre security.txt selon la RFC 9116, interroge les endpoints well-known standard et affiche votre robots.txt, dans la section Web & TLS du rapport.

Scanner votre domaine sur mlab.sh

4 Red Flags

Un security.txt expiré

Les chercheurs doivent l'ignorer, il ne leur sert donc à rien. Mettez à jour la date Expires (à moins d'un an) et programmez un rappel pour la prochaine fois.

Un security.txt sans Contact, ou avec un contact que personne ne lit

Le fichier n'existe que pour donner un contact. Envoyez un message de test à l'adresse indiquée et vérifiez que quelqu'un répond.

Des lignes Disallow qui citent admin, préprod ou sauvegardes

Vous publiez la liste des endroits où chercher. Protégez ces chemins par une authentification, puis retirez-les de robots.txt.

Des builds internes ou de debug dans assetlinks ou apple-app-site-association

Des packages en .staff, .internal ou .debug révèlent des applications qui n'avaient pas vocation à être publiques. Ne gardez que les applications publiées.

Un Canonical qui pointe vers un autre site

En général un fichier copié d'un modèle ou de la maison mère. Les chercheurs risquent de signaler à la mauvaise équipe. Rédigez un fichier propre à chaque domaine.

Propulsé par mlab.sh

Modules connexes

Votre domaine face à l'IA : llms.txt, crawlers, MCP

Ce que votre domaine dit aux IA et ce qu'il leur expose : llms.txt, règles pour les crawlers IA, découverte d'agents et serveurs MCP.

Les vulnérabilités connues de votre site

Comment un scan relie une version logicielle à des CVE, ce que signifient CVSS, EPSS et KEV, et comment prioriser les correctifs.

Comment lire un rapport de scan de domaine

Score, note, sévérités et sections du rapport : lire un scan de domaine mlab.sh et savoir quoi corriger en premier.