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 11 octobre 2026 Source : Établissements hospitaliers publics et subventionnés (listes hospitalières cantonales, art. 39 LAMal).
Entités recensées
46
46 mesurées · 0 inatteignables
Type d'infrastructure critique
Santé publique
Soins médicaux et hôpitaux
Composition du périmètre
Type des établissements recensés, indépendamment de leur résultat.
- Hôpital de soins aigus 41
- Hôpital universitaire 5
Résultats
Niveau de conformité
Sur l'ensemble des entités mesurées, y compris celles qui ne publient rien.
- Solide 2
- Partiel 11
- À renforcer 33
| Résultat | Entités | % |
|---|---|---|
| Solide | 2 | 4 % |
| Partiel | 11 | 24 % |
| À renforcer | 33 | 72 % |
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 entre types d'établissement
Part des établissements en conformité, par type d'établissement – du meilleur au moins bon.
Hôpital de soins aigus
Hôpital universitaire
- 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. | |
| 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 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 | 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 | 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 | 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é « 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. | |
| 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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. |
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 % | 68 % | 21 % | 47 |
| 2026-09 | 4 % | 24 % | 72 % | 47 |
| 2026-10 | 4 % | 24 % | 72 % | 47 |
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.