Infrastructures critiques suisses : chiffres clés de cybersécurité, comparaisons et priorités de correction pour cantons, communes, finance et hôpitaux.
Cette analyse consolide les résultats des scans de cybersécurité menés sur les infrastructures critiques suisses. Trois axes mesurés : security.txt (point de contact pour signaler une faille), en-têtes de sécurité, et sécurité e-mail (SPF, DMARC, DNSSEC).
dcod.ch
Cybersécurité • IA • Tech
Observatoire de la cybersécurité des infrastructures critiques suisses
Périmètre
Contrôle
État au 12 octobre 2026 Source : Sites officiels des communes suisses (domaines derives du projet mxmap, licence MIT).
Entités recensées
2110
2108 mesurées · 0 inatteignables · 2 sans site web
Type d'infrastructure critique
Autorités
Parlement, gouvernement, justice, administration
Résultats
Niveau de conformité
Sur l'ensemble des entités mesurées, y compris celles qui ne publient rien.
- Solide 101
- Partiel 948
- À renforcer 1059
| Résultat | Entités | % |
|---|---|---|
| Solide | 101 | 5 % |
| Partiel | 948 | 45 % |
| À renforcer | 1059 | 50 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
Cantons suisses
Communes suisses
Établissements financiers suisses
Hôpitaux suisses
Approvisionnement énergétique suisse
Transports suisses
- Solide
- Partiel
- À renforcer
Comparaison des communes par canton
Part des communes en conformité, par canton. Cette vue regroupe l'ensemble des communes de chaque canton : elle ne reflète pas le résultat du site du canton lui-même, dont le score reste réservé aux responsables sécurité concernés.
1Berne
2Appenzell Rhodes-Extérieures
3Argovie
4Zoug
5Soleure
6Bâle-Campagne
7Lucerne
8Zurich
9Saint-Gall
10Thurgovie
11Grisons
12Glaris
12Nidwald
12Obwald
15Neuchâtel
16Bâle-Ville
16Schwytz
18Genève
19Appenzell Rhodes-Intérieures
20Jura
21Vaud
22Fribourg
23Schaffhouse
23Valais
25Uri
26Tessin
- Solide
- Partiel
- À renforcer
Problèmes à corriger
Types d'erreurs rencontrés, classés par gravité et non par fréquence. La part indique combien d'entités mesurées sont touchées.
| Gravité | Contrôle | Entités | Correction recommandée |
|---|---|---|---|
| Critique | Fichier security.txt publié STXT-PRESENT | Publier un fichier texte à l'adresse /.well-known/security.txt du site, avec au moins une ligne « Contact: » et une ligne « Expires: ». Choisir une adresse générique relevée par plusieurs personnes (par exemple securite@…), jamais la boîte d'une seule personne. | |
| Critique | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC | Publier un enregistrement TXT sur _dmarc.<domaine> : commencer par « v=DMARC1; p=none; rua=mailto:dmarc@exemple.ch », analyser les rapports quelques semaines, puis durcir vers « p=quarantine » et enfin « p=reject ». | |
| Critique | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF | Dans la zone DNS du domaine (chez l'hébergeur ou le registraire qui la gère), publier un seul enregistrement TXT commençant par « v=spf1 », qui liste tous les services d'envoi légitimes et se termine par « -all ». Le temps de vérifier que tous les envois légitimes sont bien listés, « ~all » peut servir d'étape. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS | Installer un certificat valide pour le nom du site (Let's Encrypt est gratuit et se renouvelle automatiquement), le servir avec ses certificats intermédiaires, et vérifier que le renouvellement automatique fonctionne. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS certificat pour un autre nom | Émettre un certificat qui couvre le domaine et sa variante www (champ « Subject Alternative Name »), ou demander à l'hébergeur de l'activer pour ce domaine. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS site en clair seulement | Activer HTTPS (certificat Let's Encrypt gratuit, souvent disponible en un clic chez l'hébergeur), puis rediriger toutes les adresses http:// vers https://. | |
| Majeur | Chiffrement SMTP forcé en transit (MTA-STS) EMAIL-MTA-STS | Publier un enregistrement TXT sur _mta-sts.<domaine> (« v=STSv1; id=… »), puis le fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt, d'abord en « mode: testing », puis en « mode: enforce » une fois vérifié. | |
| Majeur | Réponses DNS signées et vérifiables (DNSSEC) EMAIL-DNSSEC | Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple option), puis faire publier l'enregistrement DS chez le registraire du domaine – beaucoup le font automatiquement. | |
| Majeur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS | Une fois le site entièrement servi en HTTPS, ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (un an) ; ajouter « includeSubDomains » lorsque tous les sous-domaines le sont aussi. | |
| Majeur | Redirection automatique vers HTTPS HEAD-REDIRECT | Configurer le serveur ou l'hébergement pour rediriger toute adresse en http:// vers son équivalent en https://, de préférence par une redirection permanente (301 ou 308). | |
| Majeur | Redirection automatique vers HTTPS HEAD-REDIRECT redirection vers une adresse non HTTPS | Rediriger directement vers https://<même domaine>/ dès le premier saut, sans étape intermédiaire en HTTP. | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES | Ajouter ou mettre à jour la ligne « Expires: » avec une date d'ici un an au plus, et prévoir un rappel pour la repousser avant l'échéance. | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES date de validité dépassée | Renouveler la date du champ « Expires: » (ISO 8601, par exemple dans un an) et prévoir un rappel avant la prochaine échéance. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » (surveillance seule) | Passer de « p=none » à « p=quarantine » (mise en quarantaine), puis à terme « p=reject » (rejet) une fois les rapports rua= vérifiés. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré se termine par « ~all » | Remplacer « ~all » par « -all » en fin d'enregistrement, une fois les expéditeurs légitimes bien listés (le marquage « ~all » n'est censé être qu'une étape de test). | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=quarantine » | Passer de « p=quarantine » à « p=reject » (rejet) une fois les rapports rua= vérifiés et les faux positifs écartés. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=reject » sans « rua= » | Ajouter « rua=mailto:… » à l'enregistrement : la politique de rejet reste inchangée, mais le domaine reçoit enfin des rapports sur les tentatives d'usurpation et peut vérifier que sa configuration continue de fonctionner comme prévu. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » sans « rua= » | Ajouter « rua=mailto:… » à l'enregistrement pour recevoir les rapports d'agrégation : sans eux, impossible de savoir quand durcir vers « p=quarantine » ou « p=reject » sans risquer de bloquer des courriels légitimes. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=quarantine » sans « rua= » | Ajouter « rua=mailto:… » pour recevoir des rapports, puis passer de « p=quarantine » à « p=reject » (rejet) une fois ces rapports vérifiés et les faux positifs écartés. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré se termine par « ?all » | Remplacer « ?all » par « -all » (rejet) en fin d'enregistrement, ou au minimum « ~all » (marquage) le temps d'une phase de test : « ?all » n'a jamais été qu'un état transitoire, pas une politique à conserver. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré sous-domaines moins protégés | Ajouter ou durcir « sp=reject » pour aligner la politique des sous-domaines sur celle du domaine principal – ou « sp=quarantine » a minima. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré sans terminaison « all » | Ajouter « -all » (ou « ~all » en phase de test) en fin d'enregistrement. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=reject » partiel (« pct= ») | Augmenter progressivement « pct= » jusqu'à 100 (ou le retirer, 100 étant la valeur par défaut) une fois les rapports rua= vérifiés. | |
| Majeur | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS partiellement configuré chaîne de certificats incomplète | Installer sur le serveur la chaîne complète (certificat + intermédiaires : fichier « fullchain.pem » chez Let's Encrypt, « bundle » chez les autres autorités), puis vérifier avec SSL Labs (ssllabs.com/ssltest) : la mention « Chain issues: Incomplete » doit disparaître. | |
| Mineur | Rapports d'échec de chiffrement SMTP (TLS-RPT) EMAIL-TLSRPT | Publier un enregistrement TXT sur _smtp._tls.<domaine> (« v=TLSRPTv1; rua=mailto:tls-rapports@exemple.ch »). | |
| Mineur | Autorités de certification restreintes (CAA) EMAIL-CAA | Publier dans la zone DNS du domaine un enregistrement CAA qui nomme la ou les autorités utilisées, par exemple « 0 issue "letsencrypt.org" ». | |
| Mineur | Liste des scripts et ressources autorisés (CSP) HEAD-CSP | Définir une politique adaptée au site, la tester d'abord en mode « Content-Security-Policy-Report-Only », corriger ce qu'elle signale, puis l'appliquer. | |
| Mineur | Accès aux fonctions du navigateur limité (Permissions-Policy) HEAD-PERMISSIONS | Ajouter une politique qui ferme ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Mineur | Informations limitées vers les liens sortants (Referrer-Policy) HEAD-REFERRER | Ajouter l'en-tête « Referrer-Policy: strict-origin-when-cross-origin ». | |
| Mineur | Clé de chiffrement publiée (champ Encryption) STXT-ENCRYPTION | Ajouter une ligne « Encryption: https://exemple.ch/cle-pgp.asc » pointant vers la clé publique de l'équipe de sécurité. | |
| Mineur | Protection contre l'affichage dans un cadre invisible (anti-clickjacking) HEAD-FRAME | Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive « frame-ancestors 'self' » dans la politique CSP. | |
| Mineur | Type de fichier non réinterprété par le navigateur (nosniff) HEAD-NOSNIFF | Ajouter l'en-tête « X-Content-Type-Options: nosniff » dans la configuration du serveur. | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. | |
| Mineur | Numéro de version du logiciel non divulgué HEAD-VERSION | Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (par exemple ServerTokens Prod et ServerSignature Off sous Apache, expose_php = Off pour PHP). | |
| Mineur | Fichier accessible avec et sans www STXT-BOTH-VARIANTS | Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre. | |
| Mineur | Langues de contact indiquées (champ Preferred-Languages) STXT-LANGUAGES | Ajouter une ligne « Preferred-Languages: fr, de, it, en » listant les langues acceptées pour un signalement. | |
| Mineur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS partiellement configuré durée (max-age) trop courte | Augmenter max-age à au moins 15552000 (6 mois) – idéalement 31536000 (1 an) avec includeSubDomains. | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES partiellement configuré | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. | |
| Mineur | Liste des scripts et ressources autorisés (CSP) HEAD-CSP partiellement configuré mode rapport seul | Une fois les rapports vérifiés sans faux positif, publier la même politique sous l'en-tête « Content-Security-Policy » (sans « -Report-Only ») pour qu'elle s'applique réellement. | |
| Mineur | Informations limitées vers les liens sortants (Referrer-Policy) HEAD-REFERRER partiellement configuré | Remplacer par « strict-origin-when-cross-origin », qui ne transmet que l'origine (pas le chemin complet) vers un autre site. |
Pour corriger pas à pas, les guides complets : security.txt : le guide complet du signalement des vulnérabilités · SPF, DKIM, DMARC : le guide complet de la sécurité des emails · En-têtes de sécurité HTTP : le guide complet (HSTS, CSP, cookies)
Évolution
Tendance mensuelle de l'ensemble du registre, toutes entités confondues.
| Mois | Solide | Partiel | À renforcer | Entités évaluées |
|---|---|---|---|---|
| 2026-08 | 11 % | 62 % | 27 % | 2110 |
| 2026-09 | 3 % | 45 % | 52 % | 2110 |
| 2026-10 | 5 % | 45 % | 50 % | 2110 |
Méthodologie et limites
Les évaluations sont établies à la date d'observation, sur la seule base d'informations publiquement accessibles, collectées de manière passive et sans authentification. Elles ne constituent ni un audit de sécurité, ni un test d'intrusion, ni une certification. Un résultat « solide » ne garantit pas l'absence de vulnérabilité ; un point « à renforcer » n'implique ni compromission, ni manquement à une obligation légale ou contractuelle.