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.
Toutes les mesures sont passives : elles n’observent que ce qu’un navigateur ou un serveur de messagerie reçoit déjà en se connectant normalement.
Chargement de la carte…
Au 7 août 2026, 26 sites évalués sur Cantons suisses ont un score de sécurité global : 9 cumulent de bonnes pratiques sur l'ensemble des catégories testées (security.txt, en-têtes HTTP, hygiène e-mail…).
- Solide 9 (35%)
- Partiel 16 (62%)
- À renforcer 1 (4%)
Vue nationale : 9 cantons sur 26 ont un score de sécurité global solide (35 %). 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 négligeant 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
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.
En savoir plus ↗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).
En savoir plus ↗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.
En savoir plus ↗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 ».
En savoir plus ↗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) ou ~all (marquage) : sans cela, l'enregistrement n'a pas d'effet utile, 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é 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=quarantine et p=reject. 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.
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 | 9 | 16 | 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.