La sécurité d’un site public ne se résume pas au cadenas affiché dans la barre d’adresse. Cette page réunit trois familles de mesures — le point de contact pour signaler une faille, les entêtes de sécurité transmis à chaque visite, et la protection du domaine contre l’usurpation d’e-mail — en un score unique pour chacun des 26 cantons suisses.
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 5 septembre 2026, 26 sites évalués sur Cantons suisses ont un score de sécurité global : 7 cumulent de bonnes pratiques sur l'ensemble des catégories testées (security.txt, en-têtes HTTP, hygiène e-mail…).
- Solide7(27%)
- Partiel18(69%)
- À renforcer1(4%)
Vue nationale : 7 cantons sur 26 ont un score de sécurité global solide (27 %). Le détail par canton est réservé aux responsables de sécurité (CISO) cantonaux et communaux.
Comment le score de sécurité d’un canton est-il calculé ?
Chaque canton est évalué séparément sur trois domaines, puis son score global est la moyenne des verdicts obtenus. Un domaine que nous n’avons pas pu mesurer — site injoignable au moment de l’analyse, zone DNS en panne — est exclu du calcul plutôt que compté comme un échec : on ne reproche pas à une administration une mesure que nous n’avons pas su faire.
Le résultat est publié sous forme de bande — solide, partiel, à renforcer — et non de note chiffrée. C’est un choix assumé : une note au point près inviterait au classement inverse, c’est-à-dire exactement à la liste de cibles que cet observatoire refuse d’être. Les pourcentages précis restent publiés au niveau agrégé.
Pourquoi trois domaines plutôt qu’un seul ?
Parce qu’ils protègent des choses différentes, et qu’un canton peut exceller dans l’un tout en devant renforcer les autres.
Le fichier security.txt ne protège rien par lui-même : il indique à un chercheur qui découvre une faille à qui la signaler, plutôt que de le laisser choisir entre le silence et la publication. C’est le domaine le mieux tenu par les cantons, et il fait l’objet d’une page détaillée : voir la carte security.txt des cantons suisses.
Les entêtes de sécurité protègent l’internaute pendant sa visite, dans son propre navigateur : chiffrement imposé, scripts autorisés, fenêtres invisibles empêchées. Tous les cantons redirigent désormais correctement les visiteurs arrivant en clair vers HTTPS — un acquis qui n’allait pas de soi il y a quelques années.
La protection e-mail, elle, ne concerne pas le site du tout. Elle empêche un tiers d’envoyer un courriel en se faisant passer pour le canton — un vecteur d’hameçonnage particulièrement efficace quand l’expéditeur usurpé est une autorité publique. C’est aujourd’hui le domaine le plus en retrait.
Qui peut consulter le résultat d’un canton en particulier ?
Les chiffres d’ensemble de cette page sont publics : combien de cantons appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. Le résultat détaillé d’un canton donné, en revanche, est réservé aux responsables de la sécurité des systèmes d’information (CISO) des cantons et des communes.
Un CISO qui obtient un accès voit en clair son canton et l’ensemble des communes de ce canton — de quoi agir chez lui — et les autres cantons en vue agrégée, de quoi se comparer. Le fichier security.txt fait exception et reste public sans condition : son objet même est d’être trouvé par qui cherche à signaler une faille.
Que peut faire un canton de ce constat ?
Les trois domaines n’exigent ni le même effort ni les mêmes compétences. Publier un security.txt est l’affaire d’un fichier texte. Ajouter les entêtes manquants relève de quelques lignes de configuration serveur. Renforcer la protection e-mail se joue dans la zone DNS, sans toucher au site.
Le catalogue ci-dessous détaille chaque contrôle : ce qu’il vérifie, pourquoi il compte, et comment le corriger.
Catalogue des contrôles
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.
Entêtes de sécurité
Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur.
HEAD-HTTPSConnexion chiffrée disponible (HTTPS)CritiqueSans HTTPS, tout ce qui circule entre le visiteur et le site peut être lu ou modifié en chemin. Ce contrôle vérifie que le site répond correctement en HTTPS, pas la redirection depuis l'ancienne adresse en http://.
Installer un certificat (Let's Encrypt est gratuit et automatisable) et servir le site en HTTPS.
En savoir plus ↗HEAD-REDIRECTRedirection automatique vers HTTPSMajeurSans redirection, un visiteur qui tape l'adresse sans https:// reçoit d'abord une réponse en clair : HSTS, qui suppose déjà une première visite réussie en HTTPS, ne peut s'appliquer qu'après.
Configurer le serveur pour rediriger (301 ou 302) toute requête HTTP vers l'adresse HTTPS équivalente, dès le premier saut.
- Le port 80 répond directement (le contenu est servi en clair) au lieu de rediriger vers l'adresse HTTPS.
- Une redirection a bien lieu, mais pas vers une adresse en https:// (ou sans indiquer de destination) : le premier échange reste en clair malgré tout.
HEAD-HSTSNavigateur forcé à rester en HTTPS (HSTS)MajeurIndique au navigateur de n'utiliser que HTTPS pour ce site, y compris si le visiteur tape l'adresse sans https://.
Ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (6 mois minimum recommandés).
- Aucun en-tête Strict-Transport-Security n'est envoyé : le navigateur n'est jamais forcé à rester en HTTPS pour ce site.
- L'en-tête est présent mais sans durée (max-age) exploitable : le navigateur ne peut pas retenir la consigne.
- La durée annoncée (max-age) est inférieure à 6 mois : la mesure existe, mais une visite un peu espacée suffit à la faire expirer.
HEAD-CSPListe des scripts et ressources autorisés (CSP)MineurLimite les scripts et ressources que la page a le droit de charger, ce qui réduit fortement l'impact d'une injection de code.
Définir une politique, en commençant en mode rapport (Content-Security-Policy-Report-Only) pour vérifier qu'elle ne casse rien.
- Aucune politique de sécurité de contenu n'est envoyée, ni en mode appliqué ni en mode rapport.
- La politique publiée est en mode « rapport seul » (Content-Security-Policy-Report-Only) : elle observe les violations sans encore en bloquer aucune.
HEAD-NOSNIFFType de fichier non réinterprété par le navigateur (nosniff)MineurEmpêche le navigateur de deviner le type d'un fichier, et donc d'exécuter comme script un contenu qui n'en est pas un.
Ajouter l'en-tête « X-Content-Type-Options: nosniff ».
En savoir plus ↗HEAD-FRAMEProtection contre l'affichage dans un cadre invisible (anti-clickjacking)MineurEmpêche un site tiers d'afficher les pages du site dans un cadre invisible pour faire cliquer l'internaute à son insu.
Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP.
En savoir plus ↗HEAD-REFERRERInformations limitées vers les liens sortants (Referrer-Policy)MineurContrôle les informations d'origine transmises aux sites tiers lorsqu'un visiteur suit un lien sortant.
Ajouter « Referrer-Policy: strict-origin-when-cross-origin ».
- Aucun en-tête Referrer-Policy n'est envoyé : le navigateur applique son comportement par défaut, qui varie d'un navigateur à l'autre.
- La politique publiée est « unsafe-url » : l'adresse complète (chemin compris) est transmise à chaque site tiers lié, y compris depuis une page en HTTPS vers un lien en HTTP.
HEAD-PERMISSIONSAccès aux fonctions du navigateur limité (Permissions-Policy)MineurDéclare quelles fonctionnalités du navigateur (caméra, micro, géolocalisation) la page peut solliciter.
Ajouter une politique fermant ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ».
En savoir plus ↗HEAD-VERSIONNuméro de version du logiciel non divulguéMineurUn numéro de version précis (Apache/2.4.41, PHP/7.4.3…) permet à un attaquant de cibler directement les failles connues de cette version, sans avoir à les chercher.
Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (souvent ServerTokens/ServerSignature sous Apache, expose_php sous PHP).
En savoir plus ↗HEAD-COOKIESCookies protégés (Secure, HttpOnly, SameSite)MineurSans l'attribut Secure, un cookie peut être intercepté si le site est un jour accédé en clair. Sans HttpOnly, un script injecté peut le lire. Sans SameSite, il est envoyé vers des sites tiers qui n'en ont pas besoin.
Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site.
En savoir plus ↗Sécurité e-mail
Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité.
EMAIL-SPFExpéditeurs de courrier autorisés (SPF)CritiqueDéclare quels serveurs ont le droit d'envoyer du courrier au nom du domaine. Sans lui, n'importe qui peut se faire passer pour l'entité auprès des administrés.
Publier un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés. Terminer par -all (rejet) : sans cela, l'enregistrement n'a pas d'effet contraignant réel (~all ne fait que marquer, ?all ne fait rien), et « +all » autorise au contraire le monde entier. Un seul enregistrement SPF par domaine : plusieurs annulent la protection.
- Aucun enregistrement SPF n'est publié pour ce domaine.
- Deux enregistrements SPF (ou plus) sont publiés en même temps : selon la RFC 7208, les serveurs destinataires doivent alors ignorer complètement la vérification (permerror), comme s'il n'y en avait aucun.
- L'enregistrement publié se termine par « +all », qui autorise explicitement n'importe quel serveur à envoyer du courrier au nom du domaine – une autorisation générale, pas une protection incomplète.
- L'enregistrement publié se termine par « ~all » (marquage) plutôt que « -all » (rejet) : purement indicatif, un serveur destinataire a le droit de délivrer quand même le courriel frauduleux normalement. Le domaine reste donc usurpable en pratique.
- L'enregistrement publié ne se termine ni par « -all » ni par « ~all » (et n'utilise pas non plus « redirect= ») : il ne restreint donc aucun expéditeur.
EMAIL-DMARCPolitique appliquée aux courriels frauduleux (DMARC)CritiqueIndique aux serveurs destinataires quoi faire des courriels qui échouent aux vérifications, et permet de recevoir des rapports sur les tentatives d'usurpation.
Publier un TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » pour observer, puis durcir vers p=reject (p=quarantine reste une étape intermédiaire : le courriel frauduleux atteint quand même la boîte du destinataire). Une fois à p=reject, viser pct=100 (ou l'omettre, valeur par défaut) et sp=reject si le domaine a des sous-domaines. Un seul enregistrement DMARC par domaine : plusieurs font ignorer la politique par les destinataires.
- Aucun enregistrement DMARC n'est publié sur _dmarc.<domaine>.
- Deux enregistrements DMARC (ou plus) sont publiés en même temps : selon la RFC 7489, les destinataires doivent alors ignorer la politique (permerror), comme s'il n'y en avait aucune.
- Un enregistrement DMARC existe, mais sans balise « p= » exploitable (none, quarantine ou reject) : les destinataires ne savent pas quoi faire des courriels non conformes.
- La politique publiée est « p=none » : c'est l'étape de surveillance recommandée avant de durcir, mais elle ne bloque ni ne marque encore aucun courriel frauduleux.
- La politique publiée est « p=quarantine » : les courriels frauduleux sont déviés vers les indésirables plutôt que rejetés – une réduction réelle du risque, mais le message atteint quand même la boîte du destinataire et reste à sa merci.
- La politique « p=reject » n'est appliquée qu'à une fraction des courriels frauduleux (balise « pct= » inférieure à 100) : le reste retombe sur une politique plus faible, comme si aucun rejet n'était configuré pour cette part-là.
- Le domaine lui-même est bien protégé (« p=reject »), mais ses sous-domaines le sont moins (balise « sp= » plus faible) : un courriel usurpant un sous-domaine (ex. newsletter.<domaine>) peut échapper au rejet.
EMAIL-DNSSECRéponses DNS signées et vérifiables (DNSSEC)MajeurSigne les réponses DNS du domaine, ce qui empêche de rediriger silencieusement les visiteurs ou le courrier vers un serveur illégitime.
Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple case à cocher), puis publier l'enregistrement DS chez le registraire.
En savoir plus ↗Comment la situation évolue-t-elle ?
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| 2026-07 | 0 | 0 | 0 | 0 | 0 |
| 2026-08 | 6 | 19 | 1 | 0 | 26 |
| 2026-09 | 7 | 18 | 1 | 0 | 26 |
Questions fréquentes
Que mesure exactement ce score de sécurité ?
Trois familles de contrôles passifs sur le site officiel de chaque canton : la présence et la validité d’un fichier security.txt (RFC 9116), les entêtes de sécurité HTTP renvoyés à chaque visite, et les enregistrements DNS qui protègent le domaine contre l’usurpation d’e-mail (SPF, DMARC, DNSSEC). Le score global est la moyenne des verdicts de ces trois domaines.
Pourquoi une bande plutôt qu’une note sur 100 ?
Une note au point près invite au classement inverse, c’est-à-dire à dresser une liste des administrations les plus vulnérables. Cet observatoire publie donc une bande — solide, partiel, à renforcer — qui permet de situer et de progresser sans fabriquer une liste de cibles. Les pourcentages précis restent publiés au niveau agrégé.
Ces analyses sont-elles intrusives ?
Non. Elles n’observent que ce qu’un visiteur ou un serveur de messagerie reçoit déjà en se connectant normalement : la page d’accueil, les entêtes de sa réponse, et des enregistrements DNS publics. Aucune recherche de version applicative, aucun balayage de ports, aucun test de chemin non documenté.
Un canton peut-il être bon partout sauf sur un domaine ?
Oui, et c’est le cas le plus fréquent. Les trois domaines relèvent d’équipes et de compétences différentes : le site web, la configuration serveur et la zone DNS. Un canton exemplaire sur son security.txt peut n’avoir jamais publié d’enregistrement DMARC.
À quelle fréquence ces données sont-elles mises à jour ?
Les sites sont ré-analysés régulièrement. La date de la dernière analyse figure au-dessus de chaque statistique et dans le fichier de données ouvert.
Pourquoi le résultat détaillé d’un canton n’est-il pas public ?
Le résultat individuel de chaque entité est réservé aux responsables de sécurité (CISO) des cantons et des communes.
Qui peut obtenir un accès, et que voit-il de plus ?
Les responsables de sécurité des cantons et des communes suisses, sur demande et après validation manuelle. Un accès couvre tout un canton : le CISO cantonal et celui d’une commune de ce canton voient exactement la même chose, à savoir le détail du canton et de toutes ses communes. Les autres cantons restent en vue agrégée, ce qui permet la comparaison sans exposer personne.
Une zone grise sur la carte signifie-t-elle que l’entité n’est pas évaluée ?
Pas nécessairement. Le gris couvre deux situations, que la carte distingue au clic : soit la mesure n’a pas pu se faire — site injoignable, domaine qui ne résout plus — soit l’entité est bien évaluée mais son résultat individuel est réservé. Dans ce second cas, la carte affiche à la place le résultat agrégé de l’ensemble des cantons.