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).
État au 11 octobre 2026 Source : Sites officiels des 26 cantons suisses (curation DCOD).
Entités recensées
26
26 mesurées · 0 inatteignables
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 6
- Partiel 15
- À renforcer 5
| Résultat | Entités | % |
|---|---|---|
| Solide | 6 | 23 % |
| Partiel | 15 | 58 % |
| À renforcer | 5 | 19 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
- 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.
- 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. | |
| 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 | 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 | 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 | 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=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 » | 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 | 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. | |
| 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 | 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 | 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 | 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 | Informations limitées vers les liens sortants (Referrer-Policy) HEAD-REFERRER | Ajouter l'en-tête « Referrer-Policy: strict-origin-when-cross-origin ». | |
| 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 | 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 | 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 | 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 | 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 | 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. |
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 | 23 % | 73 % | 4 % | 26 |
| 2026-09 | 23 % | 58 % | 19 % | 26 |
| 2026-10 | 23 % | 58 % | 19 % | 26 |
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.