Le security.txt est un fichier texte standardisé par la RFC 9116, publié à l’adresse /.well-known/security.txt d’un site web, qui indique publiquement à qui signaler une faille de sécurité. Pour une commune, c’est souvent la seule porte d’entrée identifiable : sans elle, un chercheur qui découvre un problème écrit au formulaire de contact général, quand il ne renonce pas.
Cette page recense la présence et la validité de ce fichier sur les sites officiels de plus de 2 100 communes suisses. Cliquez sur une canton pour voir son statut, son contact de sécurité et la date d’expiration déclarée.
Aucun scan de vulnérabilités, aucune tentative d’exploitation. Ces contrôles se limitent à lire des informations déjà publiques — les mêmes qu’un navigateur ou un serveur de messagerie reçoit de toute façon en se connectant normalement à ce site.
Chargement de la carte…
Au 18 août 2026, 2110 sites évalués sur Communes suisses (security.txt) : 865 appliquent les bonnes pratiques (Point de contact publié pour signaler une faille de sécurité selon le standard RFC 9116).
- Solide865(41%)
- Partiel88(4%)
- Non évalué1157(55%)
| Région | Sites évalués | Bonnes pratiques | % |
|---|---|---|---|
| Canton d'Appenzell Rhodes-Extérieures | 20 | 16 | 80% |
| Canton d'Appenzell Rhodes-Intérieures | 5 | 2 | 40% |
| Canton d'Argovie | 196 | 128 | 65% |
| Canton d'Obwald | 7 | 7 | 100% |
| Canton d'Uri | 19 | 2 | 11% |
| Canton de Berne | 334 | 86 | 26% |
| Canton de Bâle-Campagne | 86 | 40 | 47% |
| Canton de Bâle-Ville | 3 | 0 | 0% |
| Canton de Fribourg | 119 | 25 | 21% |
| Canton de Genève | 45 | 11 | 24% |
| Canton de Glaris | 3 | 3 | 100% |
| Canton de Lucerne | 79 | 48 | 61% |
| Canton de Neuchâtel | 24 | 0 | 0% |
| Canton de Nidwald | 11 | 11 | 100% |
| Canton de Saint-Gall | 75 | 57 | 76% |
| Canton de Schaffhouse | 26 | 6 | 23% |
| Canton de Schwytz | 30 | 20 | 67% |
| Canton de Soleure | 104 | 62 | 60% |
| Canton de Thurgovie | 80 | 59 | 74% |
| Canton de Vaud | 300 | 82 | 27% |
| Canton de Zoug | 11 | 8 | 73% |
| Canton de Zurich | 160 | 140 | 88% |
| Canton des Grisons | 100 | 25 | 25% |
| Canton du Jura | 51 | 4 | 8% |
| Canton du Tessin | 100 | 0 | 0% |
| Canton du Valais | 122 | 23 | 19% |
Catalogue des contrôles security.txt
Le score affiché plus haut agrège quatre contrôles distincts, chacun avec sa propre gravité. Voici le détail de chacun : ce qu’il vérifie, pourquoi il compte, et comment le corriger s’il échoue — la même référence que celle citée dans la colonne « Contrôles à corriger » du tableau par canton.
Détail technique de chaque contrôle ci-dessous. Sources : en-têtes HTTP, enregistrements DNS, fichier security.txt. Vérification automatique et périodique (hebdomadaire ou mensuelle selon le jeu de données) par DCOD, dans le cadre d'un observatoire public de la sécurité des sites suisses. Une question, ou besoin d'exclure un domaine ? hello@dcod.ch
security.txt
Point de contact publié pour signaler une faille de sécurité selon le standard RFC 9116.
STXT-PRESENTFichier security.txt publiéCritiqueSans point de contact publié, une personne qui découvre une faille ne sait pas à qui l'annoncer et renonce souvent.
Publier un fichier texte à l'adresse /.well-known/security.txt du site.
En savoir plus ↗STXT-CONTACTAdresse de contact valide (champ Contact)MajeurSeul champ obligatoire de la RFC 9116 : c'est lui qui porte l'adresse ou le formulaire de signalement.
Ajouter une ligne « Contact: mailto:security@exemple.ch » (répéter la ligne pour plusieurs contacts, ne pas la renommer).
En savoir plus ↗STXT-EXPIRESDate de validité renseignée (champ Expires)MajeurÉgalement obligatoire : il indique jusqu'à quand l'information de contact est considérée comme à jour.
Ajouter « Expires: » avec une date ISO 8601 future (par exemple dans un an) et penser à la renouveler.
En savoir plus ↗STXT-BOTH-VARIANTSFichier accessible avec et sans wwwMineurUn fichier servi par une seule des deux variantes reste invisible pour qui arrive par l'autre.
Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre.
Historique des évolutions
| Période | Valide | Présent (incomplet) | Expiré | Partiel | Absent | Injoignable | Total |
|---|---|---|---|---|---|---|---|
| 2026-07 | 12 | 1 | 3 | 6 | 4 | 0 | 26 |
| 2026-08 | 12 | 1 | 4 | 5 | 4 | 0 | 26 |
Le security.txt n’est qu’un des trois domaines mesurés par cet observatoire. Pour une vue d’ensemble incluant les entêtes de sécurité et la protection e-mail, voir la sécurité des sites web des communes suisses.
Pour approfondir le sujet
Pourquoi adopter security.txt pour signaler les failles plus efficacement
Simplifiez la réception de rapports de vulnérabilités avec security.txt, un standard clair qui structure le contact entre chercheurs et équipes cybersécurité. Lire la suite
Questions fréquentes
Qu’est-ce qu’un fichier security.txt ?
C’est un fichier texte standardisé (RFC 9116), placé à l’adresse /.well-known/security.txt d’un site web, qui indique publiquement comment signaler une faille de sécurité : contact, politique de divulgation, langue, date d’expiration. Il facilite la divulgation responsable des vulnérabilités.
Que signifient les différents statuts ?
Valide : fichier conforme, avec un contact et une date d’expiration future.
Présent (incomplet) : fichier trouvé mais sans tous les champs requis.
Partiel : fichier trouvé sur une seule des deux adresses du site (avec ou sans « www »), absent sur l’autre.
Expiré : date d’expiration dépassée.
Absent : aucun fichier trouvé. Injoignable : site non accessible au moment de l’analyse.
À quelle fréquence les données sont-elles mises à jour ?
La carte est ré-analysée régulièrement ; la date de la dernière analyse est indiquée sur la carte et dans le fichier de données.
Ces données sont-elles réutilisables ?
Oui. Les résultats agrégés sont publiés en JSON ouvert. Les adresses de contact ne figurent pas dans le fichier public, afin d’éviter leur collecte automatisée à des fins de spam.