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 : Exploitants et autorités des transports : chemins de fer à voie normale et à voie étroite, transports urbains, cars et bus régionaux, navigation lacustre, aéroports et navigation aérienne, transport par câble, fret ferroviaire et transport combiné, organismes de régulation et de tutelle.
Entités recensées
74
74 mesurées · 0 inatteignables
Type d'infrastructure critique
Transports
Aéroports et espace aérien, Cars et bus régionaux, Ferroviaire national (voie normale), Ferroviaire régional (voie étroite), Fret ferroviaire et transport combiné, Navigation lacustre concédée, Régulation et tutelle, Transport par câble et remontées concédées, Transports urbains (trams, trolleybus, métros)
Composition du périmètre
Type des établissements recensés, indépendamment de leur résultat.
- Ferroviaire régional (voie étroite) 21
- Transports urbains (trams, trolleybus, métros) 12
- Transport par câble et remontées concédées 9
- Aéroports et espace aérien 8
- Navigation lacustre concédée 7
- Cars et bus régionaux 6
- Fret ferroviaire et transport combiné 5
- Régulation et tutelle 3
- Ferroviaire national (voie normale) 3
Résultats
Niveau de conformité
Sur l'ensemble des entités mesurées, y compris celles qui ne publient rien.
- Solide 4
- Partiel 19
- À renforcer 51
| Résultat | Entités | % |
|---|---|---|
| Solide | 4 | 5 % |
| Partiel | 19 | 26 % |
| À renforcer | 51 | 69 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
- Solide
- Partiel
- À renforcer
Comparaison entre types d'établissement
Part des établissements en conformité, par type d'établissement – du meilleur au moins bon.
- 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 | 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=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=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 » 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 » 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=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=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é 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 | 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. | |
| 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 | 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 | 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 | 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 | 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 | 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 | 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. |
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.
Pas encore d'historique pour ce contrôle : la courbe apparaît dès que deux scans complets ont eu lieu sur des mois différents.
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.