Ajouter security.txt en 5 minutes — un guide de divulgation des vulnérabilités | Scanthra

Scanthra · 6 min de lecture · Mis à jour Mai 2026

Ce qu'est vraiment security.txt

security.txt est un petit fichier texte lisible par machine que tu publies sur ton site web. C'est l'équivalent dans le monde de la sécurité de robots.txt : un emplacement connu, une syntaxe simple et un objectif clair. Son rôle est de répondre à une question pour quelqu'un qui pense avoir trouvé une vulnérabilité sur ton site — « à qui je dis ça, et comment ? »

Le format est normalisé dans l' IETF RFC 9116 (« Un format de fichier pour faciliter la divulgation de vulnérabilités de sécurité »). Il est devenu un Standard proposé en 2022, donc ce n'est plus un brouillon ou une curiosité — c'est la façon convenue de faire ça.

Pourquoi ça compte même si tu n'es pas une banque

Trois raisons pour lesquelles ça vaut les cinq minutes :

• Les chercheurs peuvent te contacter. Sans canal clair, les découvreurs bien intentionnés abandonnent, publient le problème publiquement, ou bombardent ton formulaire de contact générique. Une adresse documentée attrape le problème tôt, de façon privée.
• Les achats et les questionnaires l'attendent. Les questionnaires de sécurité fournisseurs (SIG, CAIQ, questionnaires d'entreprise personnalisés) et les check-lists aux formes NIS2 (directive UE sur la cybersécurité) demandent de plus en plus « publiez-vous une politique de divulgation des vulnérabilités ? ». Un security.txt en ligne est la réponse affirmative la moins coûteuse possible.
• Ça signale la maturité. Un site avec un security.txt à jour donne l'impression d'appartenir à quelqu'un qui a réfléchi à ce qui se passe quand quelque chose tourne mal. Ça seul te fait sortir du dernier quartile.

Les champs définis par RFC 9116

Seuls Contact et Expires sont obligatoires. Les autres sont optionnels mais utiles.

• Contact: — obligatoire. Une ou plusieurs façons de te joindre : un e-mail (préfixé par mailto:), un numéro de téléphone (tel:), ou une URL de signalement (https://). Plusieurs lignes Contact sont autorisées ; liste-les par ordre de préférence.
• Expires: — obligatoire. Un horodatage ISO 8601 après lequel ce fichier ne doit plus être considéré comme fiable. La plupart des équipes le règlent 6 à 12 mois dans le futur et le renouvellent sur rappel calendrier.
• Encryption: — une URL vers ta clé publique PGP, si tu veux des rapports chiffrés. Optionnel mais apprécié.
• Acknowledgments: — une URL vers une page qui remercie les chercheurs qui ont signalé des problèmes de façon responsable. Un petit geste sympa.
• Preferred-Languages: — des tags de langue BCP 47 séparés par des virgules (par exemple fr, en). Tu peux l'omettre — la plupart des équipes comprennent l'anglais plus leur propre langue de toute façon.
• Canonical: — l'URL canonique de ce fichier. Utile si ton site est accessible sur plusieurs noms d'hôte ; ça indique aux analyseurs quelle copie fait autorité.
• Policy: — une URL vers ta politique complète de divulgation des vulnérabilités : périmètre, clause de protection, délai de réponse attendu.
• Hiring: — une URL vers ta page de recrutement pour l'équipe sécurité. Oui, c'est dans la spec.
• CSAF: — une URL vers un fichier de métadonnées de fournisseur CSAF 2.0. Pertinent uniquement si tu publies des avis lisibles par machine ; les petites entreprises peuvent l'ignorer.

Un exemple à copier-coller que tu peux vraiment utiliser

Remplace l'e-mail, les dates et les URLs par les tiens. Garde le fichier en ASCII pur (sans BOM) et utilise des fins de ligne Unix. Les lignes commençant par # sont des commentaires.

# security.txt for example.com
# Please report security issues using the contacts below.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-05-01T00:00:00.000Z
Encryption: https://example.com/.well-known/pgp-key.txt
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: fr, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

Où le mettre

L'emplacement canonique est :

https://tondomaine.com/.well-known/security.txt

L'emplacement historique /security.txt à la racine du document est aussi toléré par la plupart des outils, mais le chemin /.well-known/ est celui que prescrit RFC 9116 — utilise-le.

nginx

location = /.well-known/security.txt {
    alias /var/www/example.com/.well-known/security.txt;
    default_type text/plain;
    add_header Cache-Control "public, max-age=3600";
}

Apache

<Files "security.txt">
    ForceType text/plain
    Header set Cache-Control "public, max-age=3600"
</Files>

Place simplement le fichier à /var/www/example.com/.well-known/security.txt et assure-toi qu'Apache est autorisé à servir les répertoires cachés (certaines configurations par défaut bloquent les chemins préfixés par .).

Hébergeurs statiques, WordPress, Cloudflare Pages, Vercel, Netlify

Dépose un fichier nommé security.txt dans un dossier nommé .well-known dans ton répertoire d'assets publics et redéploie. La plupart des hébergeurs statiques servent les répertoires cachés sans problème ; vérifie en visitant l'URL juste après le déploiement.

Le signer (optionnel mais propre)

RFC 9116 permet que le fichier soit un message PGP signé en clair. La plupart des petites entreprises ne s'en donnent pas la peine — et c'est bien. Si tu publies déjà une clé PGP, signer rend plus difficile pour quelqu'un d'usurper le fichier via un hôte compromis. Sinon, passe ; un fichier non signé est parfaitement valide.

Les erreurs courantes à éviter

• Expires manquant. Une ligne Expires absente ou expirée rend le fichier invalide selon la spec. Les analyseurs avertiront ou le rejetteront.
• Mauvais type MIME. Le fichier doit être servi en text/plain ; parfois un serveur web renvoie application/octet-stream et casse l'analyse.
• HTTPS uniquement. security.txt doit être servi en HTTPS sur son URL canonique. Une version en HTTP simple est ignorée.
• Boîte personnelle dans Contact. Utilise une adresse de rôle comme security@ qui survit aux changements de personnel, pas marie@.
• Renouvellement oublié. Mets la date Expires dans le même calendrier que celui où tu renouvelles tes certificats TLS. Un security.txt expiré est pire que rien — ça dit aux chercheurs que l'équipe dort.

Comment Scanthra détecte ça

Notre module M10 robots et well-known vérifie si /.well-known/security.txt existe et est accessible sur l'URL HTTPS canonique. S'il manque, on signale une observation de faible gravité plutôt qu'un problème — c'est un « c'est bien d'avoir, pas une urgence » — et on inclut ce guide comme correctif suggéré. Les sites qui publient déjà un fichier valide reçoivent un discret coup de pouce dans la carte de conformité.