L’approvisionnement en électricité, en gaz naturel et en pétrole forme le secteur « Énergie » de la stratégie nationale de protection des infrastructures critiques de la Confédération : une panne ou une attaque y touche directement la population et l’économie. Ce secteur repose sur Swissgrid pour le réseau de transport à très haute tension, plus de 550 gestionnaires de réseau de distribution recensés par l’ElCom, les exploitants de centrales hydrauliques et nucléaires, les négociants, les réseaux de gaz et la filière pétrolière, sous la surveillance de l’ElCom, de l’OFEN et de l’OFAE. Cette page mesure la sécurité de leurs sites publics sur trois domaines : point de contact de sécurité, entêtes HTTP, protection contre l’usurpation d’e-mail.
Pour de nombreux gestionnaires de réseau communaux, le site mesuré est celui de la commune, déclaré comme tel à l’ElCom. Cette mesure ne dit rien de la sécurité des installations elles-mêmes (réseaux, centrales, systèmes de conduite industriels) : la carte n’est pas le territoire.
Analyses cybersécurité passives : Aucun scan de vulnérabilités, aucune tentative d’accès ni d’exploitation. Les contrôles se limitent à la lecture d’informations publiques que tout navigateur ou serveur de messagerie reçoit lors d’une connexion ordinaire au site.
Chargement de la carte…
Au 9 octobre 2026, 493 sites des acteurs de l'approvisionnement énergétique suisse évalués sur l'ensemble des catégories testées (security.txt, en-têtes HTTP, hygiène e-mail…) : 21 cumulent de bonnes pratiques partout.
- Solide21(4%)
- Partiel173(35%)
- À renforcer299(61%)
Ces chiffres disent où en est le périmètre aujourd'hui. L'analyse consolidée montre leur évolution mois après mois et le plan d'action classé par gravité : voir l'analyse consolidée
Historique des évolutions
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| octobre 2026 | 21 | 173 | 299 | 0 | 493 |
Catalogue des contrôles
Voici le détail de chaque contrôle, regroupé par famille : fichier security.txt, en-têtes HTTP, enregistrements DNS. Chacun est évalué « Solide », « Partiel » ou « À renforcer » ; un contrôle qui n'a pas pu être mesuré (site injoignable, réponse DNS en échec) est « Non évalué » et ne compte ni comme réussite, ni comme défaut. Une question, ou besoin d'exclure un domaine ? Passez par le formulaire de contact.
security.txt
Point de contact publié pour signaler une faille de sécurité selon le standard RFC 9116 : qui prévenir, et dans quel délai la réponse est garantie à jour.
Guide complet : security.txt : le guide complet du signalement des vulnérabilités
STXT-PRESENTFichier security.txt publiéCritiquePourquoi c'est important. Quand une personne découvre une faille sur le site – un chercheur, un citoyen attentif -, elle doit savoir à qui la signaler. Sans point de contact publié, elle renonce souvent, ou rend la faille publique sans prévenir : l'entité l'apprend alors en même temps que les attaquants. L'Office fédéral de la cybersécurité (OFCS) attend des organisations qu'elles désignent ce contact à l'avance.
Comment ça fonctionne. Le fichier security.txt est un petit fichier texte au format standard (RFC 9116), placé à une adresse fixe du site : /.well-known/security.txt. Les chercheurs et les outils de signalement savent l'y trouver. Il contient au minimum une adresse de contact et une date de validité.
Comment c'est évalué.
- Solide : le fichier est publié à l'adresse attendue.
- À renforcer : le site répond, mais aucun fichier n'est publié à l'adresse attendue.
Gravité critique : s'il est « À renforcer », toute la famille « security.txt » est classée « À renforcer », quels que soient les autres résultats ; s'il est « Partiel », elle ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Site officiel – securitytxt.orgSTXT-CONTACTAdresse de contact valide (champ Contact)MajeurPourquoi c'est important. C'est l'information essentielle du fichier : l'adresse ou le formulaire où envoyer un signalement. Un fichier sans contact ne permet à personne de signaler quoi que ce soit.
Comment ça fonctionne. La ligne « Contact: » indique une adresse e-mail (mailto:), un formulaire web (https://) ou un numéro de téléphone. Elle peut être répétée pour proposer plusieurs moyens de contact.
Comment c'est évalué.
- Solide : le fichier indique au moins un contact.
- À renforcer : le fichier existe, mais sans ligne « Contact: » exploitable.
Gravité majeure : s'il est « À renforcer », la famille « security.txt » ne peut pas dépasser « Partiel ».
Comment corriger. Ajouter une ligne « Contact: mailto:securite@exemple.ch » – une ligne par moyen de contact.
Spécification RFC 9116 (champ Contact)STXT-EXPIRESDate de validité renseignée (champ Expires)MajeurPourquoi c'est important. Un contact publié il y a des années n'est peut-être plus relevé. La date de validité dit jusqu'à quand l'information est garantie à jour ; passé cette date, les outils de signalement considèrent le fichier comme périmé et l'ignorent.
Comment ça fonctionne. La ligne « Expires: » porte une date au format international, par exemple 2027-06-30T00:00:00Z. La norme recommande une échéance à moins d'un an, à repousser à chaque relecture du fichier.
Comment c'est évalué.
- Solide : une date de validité future est indiquée.
- À renforcer : la date est dépassée, ou absente.
Gravité majeure : s'il est « À renforcer », la famille « security.txt » ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Spécification RFC 9116 (champ Expires)STXT-BOTH-VARIANTSFichier accessible avec et sans wwwMineurPourquoi c'est important. Un site est souvent joignable à deux adresses, avec et sans « www ». Si le fichier n'est servi que sur l'une, une personne ou un outil qui passe par l'autre conclut qu'il n'existe pas.
Comment ça fonctionne. La mesure interroge les deux variantes de l'adresse, par exemple exemple.ch et www.exemple.ch.
Comment c'est évalué.
- Solide : le fichier est accessible sur les deux variantes, directement ou par redirection.
- À renforcer : il n'est accessible que sur l'une des deux.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre.
STXT-ENCRYPTIONClé de chiffrement publiée (champ Encryption)MineurPourquoi c'est important. Un signalement de faille décrit souvent comment attaquer le site. Envoyé en clair par e-mail, il peut être intercepté. Une clé de chiffrement publiée permet d'envoyer ce rapport de façon confidentielle.
Comment ça fonctionne. La ligne « Encryption: » pointe vers la clé publique (souvent OpenPGP) de l'équipe qui reçoit les signalements. C'est un champ facultatif de la norme : recommandé, jamais exigé.
Comment c'est évalué.
- Solide : une clé de chiffrement est indiquée.
- À renforcer : aucune clé n'est indiquée. Simple recommandation : ce champ ne pèse que peu dans le score.
Champ facultatif : recommandé, jamais exigé. Il compte pour peu dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter une ligne « Encryption: https://exemple.ch/cle-pgp.asc » pointant vers la clé publique de l'équipe de sécurité.
Spécification RFC 9116 (champ Encryption)STXT-LANGUAGESLangues de contact indiquées (champ Preferred-Languages)MineurPourquoi c'est important. En Suisse, un signalement peut arriver en français, en allemand, en italien ou en anglais. Indiquer les langues acceptées évite qu'un rapport reste sans suite faute d'être compris.
Comment ça fonctionne. La ligne « Preferred-Languages: » liste les langues dans lesquelles l'équipe peut traiter un signalement, par exemple fr, de, it, en. C'est un champ facultatif de la norme.
Comment c'est évalué.
- Solide : les langues acceptées sont indiquées.
- À renforcer : aucune langue n'est indiquée. Simple recommandation : ce champ ne pèse que peu dans le score.
Champ facultatif : recommandé, jamais exigé. Il compte pour peu dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter une ligne « Preferred-Languages: fr, de, it, en » listant les langues acceptées pour un signalement.
Spécification RFC 9116 (champ Preferred-Languages)Entêtes de sécurité
Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur.
Guide complet : En-têtes de sécurité HTTP : le guide complet (HSTS, CSP, cookies)
HEAD-HTTPSConnexion chiffrée disponible (HTTPS)CritiquePourquoi c'est important. Sans connexion chiffrée, tout ce qui circule entre le visiteur et le site – formulaires, identifiants, documents – peut être lu ou modifié par quelqu'un placé sur le réseau (Wi-Fi public, équipement compromis). Les navigateurs signalent d'ailleurs ces sites comme « non sécurisés ».
Comment ça fonctionne. HTTPS chiffre la connexion grâce à un certificat : une pièce d'identité numérique du site, délivrée par une autorité reconnue. Pour être accepté, le certificat doit être en cours de validité, émis pour le bon nom de domaine et servi complet, avec ses certificats intermédiaires. Ce contrôle porte sur la connexion chiffrée elle-même ; la redirection depuis l'adresse en http:// fait l'objet d'un contrôle distinct.
Comment c'est évalué.
- Solide : le site répond en HTTPS avec un certificat accepté.
- Partiel : le certificat est valable mais servi sans ses certificats intermédiaires (chaîne incomplète). Les navigateurs de bureau complètent souvent la chaîne d'eux-mêmes, mais des applications, des mobiles ou des services automatisés refusent la connexion.
- À renforcer : pas de connexion chiffrée (site servi seulement en clair, aucun service sur le port HTTPS), ou certificat refusé : expiré, émis pour un autre nom ou auto-signé. Le navigateur affiche alors un avertissement de sécurité.
Gravité critique : s'il est « À renforcer », toute la famille « Entêtes de sécurité » est classée « À renforcer », quels que soient les autres résultats ; s'il est « Partiel », elle ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Guide OWASP – Transport Layer SecurityHEAD-REDIRECTRedirection automatique vers HTTPSMajeurPourquoi c'est important. Beaucoup de visiteurs tapent l'adresse sans « https:// » ou suivent un ancien lien en http://. Sans redirection, cette première visite se fait en clair et peut être détournée vers un faux site avant même que la connexion chiffrée soit proposée.
Comment ça fonctionne. Quand le navigateur demande l'adresse en http://, le serveur doit répondre aussitôt que la page se trouve à l'adresse en https://. Une redirection permanente (code 301 ou 308) est préférable : le navigateur la mémorise pour les visites suivantes.
Comment c'est évalué.
- Solide : l'adresse en http:// renvoie immédiatement vers une adresse en https://.
- À renforcer : l'adresse en http:// affiche le site en clair, ou renvoie vers une adresse qui n'est pas en https://.
Gravité majeure : s'il est « À renforcer », la famille « Entêtes de sécurité » ne peut pas dépasser « Partiel ».
Comment corriger. 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).
Guide MDN – Redirections HTTPHEAD-HSTSNavigateur forcé à rester en HTTPS (HSTS)MajeurPourquoi c'est important. Même avec une redirection, la toute première requête part en clair et peut être interceptée par un attaquant placé sur le réseau. HSTS demande au navigateur de ne plus jamais contacter le site autrement qu'en HTTPS : après une première visite, cette fenêtre d'attaque disparaît.
Comment ça fonctionne. Le site envoie l'en-tête « Strict-Transport-Security » avec une durée (max-age, en secondes) pendant laquelle le navigateur doit retenir la consigne ; chaque visite la prolonge. L'option includeSubDomains étend la règle aux sous-domaines.
Comment c'est évalué.
- Solide : l'en-tête est envoyé avec une durée d'au moins 6 mois (15 552 000 secondes) ; un an est recommandé.
- Partiel : l'en-tête est envoyé, mais pour moins de 6 mois : la protection s'éteint si le visiteur revient rarement.
- À renforcer : aucun en-tête, ou un en-tête sans durée exploitable.
Gravité majeure : s'il est « À renforcer », la famille « Entêtes de sécurité » ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Guide MDN – HSTSHEAD-CSPListe des scripts et ressources autorisés (CSP)MineurPourquoi c'est important. Si un attaquant parvient à glisser du code dans une page – par un formulaire mal protégé, un module compromis -, ce code s'exécute chez chaque visiteur et peut voler des données ou renvoyer vers un faux site. Une politique CSP indique au navigateur quelles sources de scripts sont légitimes : tout le reste est bloqué.
Comment ça fonctionne. L'en-tête « Content-Security-Policy » liste les origines autorisées : le site lui-même, tel service de statistiques, etc. Une variante « Report-Only » permet de tester la politique : le navigateur signale ce qu'il aurait bloqué, sans rien bloquer. C'est le seul contrôle qui demande un vrai travail d'intégration au site, d'où sa gravité mineure malgré son poids.
Comment c'est évalué.
- Solide : une politique est appliquée.
- Partiel : une politique existe en mode test (Report-Only) : la démarche est engagée, mais rien n'est encore bloqué.
- À renforcer : aucune politique, ni appliquée ni en test.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. 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.
Guide MDN – Content-Security-PolicyHEAD-NOSNIFFType de fichier non réinterprété par le navigateur (nosniff)MineurPourquoi c'est important. Certains navigateurs devinent le type d'un fichier d'après son contenu. Un attaquant peut en profiter pour faire exécuter comme programme un fichier déposé sur le site, une image ou un document piégé. L'en-tête nosniff interdit cette devinette.
Comment ça fonctionne. Le site envoie « X-Content-Type-Options: nosniff » : le navigateur s'en tient alors au type de fichier annoncé par le serveur.
Comment c'est évalué.
- Solide : l'en-tête est envoyé.
- À renforcer : l'en-tête est absent.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter l'en-tête « X-Content-Type-Options: nosniff » dans la configuration du serveur.
Guide MDN – X-Content-Type-OptionsHEAD-FRAMEProtection contre l'affichage dans un cadre invisible (anti-clickjacking)MineurPourquoi c'est important. Un site malveillant peut afficher les pages de l'entité dans un cadre invisible, superposé à ses propres boutons, pour faire cliquer le visiteur à son insu – valider un paiement, modifier un réglage. C'est le « clickjacking ».
Comment ça fonctionne. Deux moyens équivalents l'empêchent : l'en-tête X-Frame-Options, ancien et compris partout, ou la directive frame-ancestors d'une politique CSP, plus moderne et prioritaire dans les navigateurs récents. Les deux peuvent coexister.
Comment c'est évalué.
- Solide : l'un ou l'autre est présent.
- À renforcer : aucun des deux n'est présent.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive « frame-ancestors 'self' » dans la politique CSP.
Guide MDN – X-Frame-OptionsHEAD-REFERRERInformations limitées vers les liens sortants (Referrer-Policy)MineurPourquoi c'est important. Quand un visiteur suit un lien vers un autre site, son navigateur peut transmettre l'adresse de la page qu'il quitte. Cette adresse contient parfois des informations sensibles : numéro de dossier, terme recherché, jeton d'accès.
Comment ça fonctionne. L'en-tête « Referrer-Policy » règle ce qui est transmis. La valeur « strict-origin-when-cross-origin » ne communique aux autres sites que le nom du site d'origine, jamais l'adresse complète de la page.
Comment c'est évalué.
- Solide : une politique est définie (autre que unsafe-url).
- Partiel : la politique « unsafe-url » est choisie : l'adresse complète de la page est transmise à tous les sites liés.
- À renforcer : aucune politique : chaque navigateur applique alors son propre comportement.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter l'en-tête « Referrer-Policy: strict-origin-when-cross-origin ».
Guide MDN – Referrer-PolicyHEAD-PERMISSIONSAccès aux fonctions du navigateur limité (Permissions-Policy)MineurPourquoi c'est important. Une page peut demander l'accès à la caméra, au micro ou à la position du visiteur. Si le site n'en a pas besoin, autant fermer ces portes : un script injecté ou un contenu tiers intégré ne pourra pas les solliciter.
Comment ça fonctionne. L'en-tête « Permissions-Policy » liste les fonctions du navigateur que la page et ses contenus intégrés ont le droit d'utiliser.
Comment c'est évalué.
- Solide : une politique est définie.
- À renforcer : aucune politique n'est définie.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter une politique qui ferme ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ».
Guide MDN – Permissions-PolicyHEAD-VERSIONNuméro de version du logiciel non divulguéMineurPourquoi c'est important. Un serveur qui annonce son logiciel et sa version exacte – par exemple « Apache/2.4.41 » ou « PHP/7.4.3 » – indique aux attaquants quelles failles connues essayer en premier, sans effort de recherche.
Comment ça fonctionne. L'information apparaît dans les en-têtes « Server » et « X-Powered-By » de chaque réponse. Masquer le numéro ne corrige aucune faille, mais retire une indication précieuse aux attaquants. Le nom du logiciel seul, sans numéro, est accepté.
Comment c'est évalué.
- Solide : aucun numéro de version n'est annoncé.
- À renforcer : un numéro de version est visible dans les en-têtes.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. 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).
Projet OWASP – En-têtes de sécuritéHEAD-COOKIESCookies protégés (Secure, HttpOnly, SameSite)MineurPourquoi c'est important. Les cookies portent souvent la session d'un utilisateur connecté. Mal protégé, un cookie peut être volé – sur un réseau non chiffré, par un script injecté – et permettre de se faire passer pour cet utilisateur.
Comment ça fonctionne. Trois attributs protègent un cookie : Secure (envoyé seulement en HTTPS), HttpOnly (illisible par les scripts de la page) et SameSite (non envoyé lors de requêtes provenant d'autres sites). Seuls les cookies posés par la page d'accueil, dans la première réponse du serveur, sont examinés ; un site qui n'en pose aucun n'est pas évalué sur ce point.
Comment c'est évalué.
- Solide : tous les cookies portent les trois attributs.
- Partiel : tous les cookies sont marqués Secure, mais il manque HttpOnly ou SameSite sur au moins l'un d'eux.
- À renforcer : au moins un cookie n'est pas marqué Secure.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site.
Guide MDN – Set-CookieSécurité e-mail
Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité.
Guide complet : SPF, DKIM, DMARC : le guide complet de la sécurité des emails
EMAIL-SPFExpéditeurs de courrier autorisés (SPF)CritiquePourquoi c'est important. Sans SPF, n'importe qui peut envoyer un e-mail qui semble venir de l'entité – fausse facture, faux avis officiel, demande de paiement -, et les serveurs des destinataires n'ont aucun moyen de le reconnaître comme faux. C'est la porte d'entrée classique de l'hameçonnage.
Comment ça fonctionne. SPF est une liste publiée dans le DNS du domaine : elle nomme les serveurs autorisés à envoyer du courrier en son nom (serveur de messagerie, service d'infolettre…). Elle se termine par une consigne pour tous les autres serveurs, et c'est cette consigne qui fait la protection : « -all » demande de rejeter leurs e-mails ; « ~all » demande seulement de les marquer comme suspects, sans obligation ; « ?all » ne demande rien ; « +all » autorise tout le monde.
Comment c'est évalué.
- Solide : la liste se termine par « -all » : tout expéditeur non autorisé doit être rejeté. Une liste qui renvoie à celle d'un autre domaine (redirect=) est également acceptée.
- Partiel : la liste existe, mais ne demande pas le rejet : « ~all » (simple marquage), « ?all » (aucune consigne) ou pas de consigne finale du tout. Un faux e-mail peut encore arriver en boîte de réception.
- À renforcer : aucune liste ; deux listes publiées en même temps (les destinataires doivent alors les ignorer toutes) ; ou une liste en « +all », qui autorise n'importe quel serveur.
Gravité critique : s'il est « À renforcer », toute la famille « Sécurité e-mail » est classée « À renforcer », quels que soient les autres résultats ; s'il est « Partiel », elle ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Spécification RFC 7208 (SPF)EMAIL-DMARCPolitique appliquée aux courriels frauduleux (DMARC)CritiquePourquoi c'est important. SPF permet de reconnaître un faux e-mail ; DMARC dit au destinataire ce qu'il doit en faire. Sans DMARC, ou avec une politique trop souple, un e-mail qui usurpe l'entité arrive en boîte de réception. DMARC permet aussi de recevoir des rapports qui révèlent qui envoie du courrier au nom du domaine.
Comment ça fonctionne. DMARC est un enregistrement DNS publié sur _dmarc.<domaine>. Sa politique (p=) connaît trois niveaux : « none » observe sans rien bloquer, « quarantine » envoie les faux e-mails dans les indésirables, « reject » les refuse. La balise rua= désigne l'adresse qui reçoit les rapports. Deux réglages peuvent affaiblir un « reject » : pct= (appliqué à une partie des messages seulement) et sp= (règle plus souple pour les sous-domaines). Le chemin habituel : commencer en « none » avec rua= pour repérer tous les envois légitimes, puis passer à « quarantine », enfin à « reject ».
Comment c'est évalué.
- Solide : « p=reject » appliqué à tous les messages et à tous les sous-domaines, avec une adresse de rapports (rua=).
- Partiel : une politique existe, mais ne bloque pas tout : « p=none » (observation seulement), « p=quarantine » (indésirables plutôt que rejet), « p=reject » limité par pct= ou sp=, ou toute politique sans adresse de rapports. Le domaine n'est pas encore pleinement protégé.
- À renforcer : aucune politique DMARC ; deux enregistrements publiés en même temps (ignorés tous les deux) ; ou un enregistrement sans politique p= lisible.
Gravité critique : s'il est « À renforcer », toute la famille « Sécurité e-mail » est classée « À renforcer », quels que soient les autres résultats ; s'il est « Partiel », elle ne peut pas dépasser « Partiel ».
Comment corriger. 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 ».
Spécification RFC 7489 (DMARC)EMAIL-DNSSECRéponses DNS signées et vérifiables (DNSSEC)MajeurPourquoi c'est important. Le DNS est l'annuaire d'Internet : il traduit le nom du domaine en adresses de serveurs, y compris pour le courrier. Sans signature, un attaquant peut falsifier ces réponses et envoyer discrètement visiteurs ou e-mails vers ses propres serveurs. DNSSEC protège aussi SPF et DMARC, publiés dans ce même annuaire.
Comment ça fonctionne. DNSSEC signe électroniquement les réponses du DNS du domaine ; les résolveurs qui vérifient ces signatures rejettent toute réponse falsifiée. L'activation se fait en deux temps : signature de la zone chez l'hébergeur DNS, puis publication d'une empreinte (enregistrement DS) chez le registraire.
Comment c'est évalué.
- Solide : les réponses DNS du domaine sont signées, et la signature est valide.
- À renforcer : la zone DNS n'est pas signée.
Gravité majeure : s'il est « À renforcer », la famille « Sécurité e-mail » ne peut pas dépasser « Partiel ».
Comment corriger. 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.
Guide nic.ch – DNSSECEMAIL-MTA-STSChiffrement SMTP forcé en transit (MTA-STS)MajeurPourquoi c'est important. Entre deux serveurs de messagerie, le chiffrement des e-mails est proposé mais pas imposé : un attaquant placé sur le réseau peut le faire sauter et lire les messages en clair. MTA-STS permet au domaine d'exiger le chiffrement pour le courrier qui lui est destiné.
Comment ça fonctionne. Le domaine publie un enregistrement DNS (_mta-sts) qui annonce une politique, et un petit fichier sur https://mta-sts.<domaine> qui la détaille. En mode « enforce », les serveurs expéditeurs refusent de livrer sans chiffrement. Seule la présence de l'enregistrement DNS est mesurée ici, pas le mode choisi.
Comment c'est évalué.
- Solide : l'enregistrement MTA-STS est publié.
- À renforcer : aucun enregistrement MTA-STS.
Gravité majeure : s'il est « À renforcer », la famille « Sécurité e-mail » ne peut pas dépasser « Partiel ».
Comment corriger. 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é.
Spécification RFC 8461 (MTA-STS)EMAIL-CAAAutorités de certification restreintes (CAA)MineurPourquoi c'est important. Pour se faire passer pour le site en HTTPS, un attaquant doit obtenir un certificat à son nom. Par défaut, n'importe laquelle des nombreuses autorités de certification peut en émettre un. CAA restreint cette liste aux seules autorités choisies par l'entité.
Comment ça fonctionne. L'enregistrement CAA, publié dans le DNS du domaine, nomme les autorités autorisées, par exemple Let's Encrypt. Les autorités sont tenues de le consulter avant d'émettre un certificat.
Comment c'est évalué.
- Solide : un enregistrement CAA est publié.
- À renforcer : aucun enregistrement CAA : toute autorité peut émettre un certificat pour le domaine.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. 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" ».
PKI Consortium – Certification Authority AuthorizationEMAIL-TLSRPTRapports d'échec de chiffrement SMTP (TLS-RPT)MineurPourquoi c'est important. Si les autres serveurs n'arrivent pas à livrer un e-mail chiffré au domaine – certificat expiré, configuration cassée, attaque -, personne n'est prévenu. TLS-RPT leur demande d'envoyer un rapport : un problème de messagerie entrante est alors repéré rapidement.
Comment ça fonctionne. Un enregistrement DNS sur _smtp._tls.<domaine> indique l'adresse qui reçoit ces rapports. Il complète MTA-STS.
Comment c'est évalué.
- Solide : l'enregistrement TLS-RPT est publié.
- À renforcer : aucun enregistrement TLS-RPT.
Gravité mineure : il compte dans le score de la famille, sans jamais plafonner sa note.
Comment corriger. Publier un enregistrement TXT sur _smtp._tls.<domaine> (« v=TLSRPTv1; rua=mailto:tls-rapports@exemple.ch »).
Spécification RFC 8460 (TLS-RPT)Questions fréquentes
Ces analyses de cybersécurité sont-elles intrusives ?
Non. Tout ce qui est mesuré ici est public et déjà lu par n’importe quel visiteur ou serveur de messagerie : les en-têtes renvoyés par la page d’accueil, des enregistrements DNS interrogés à chaque courriel reçu, et le fichier security.txt là où il est publié. S’y ajoutent deux bases publiques, consultées sans jamais contacter l’entité : la liste de préchargement HSTS intégrée aux navigateurs et la base de routage du RIPE NCC (RIPEstat). Aucun test d’intrusion, aucune recherche de vulnérabilité, aucune tentative d’authentification, aucun formulaire soumis. Une seule requête par domaine et par passage sert toutes les familles de contrôles à la fois, et le User-Agent des sondes désigne cette page, pour qu’un exploitant qui inspecte ses journaux sache d’où vient le trafic.
Pourquoi le résultat détaillé des entités n’est-il pas public ?
Publier « tel site n’applique pas telle protection » revient à dresser une liste de cibles, ce qui n’aide personne à corriger. Cette page publie donc des agrégats : combien d’entités appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. La carte montre le verdict de chaque entité, jamais la liste de ses manques. Le fichier security.txt fait exception et reste public car il permet de désigner à qui signaler une faille.
Qui peut consulter le résultat détaillé d’une entité ?
Le responsable de la sécurité des systèmes d’information (CISO) de l’entité concernée, ou de la collectivité dont elle dépend : un CISO cantonal voit son canton et l’ensemble des communes de ce canton, un CISO communal voit sa commune. Des portées sectorielle et nationale existent pour les organisations qui coordonnent plusieurs établissements.
Qui peut obtenir un accès, que voit-il de plus, et comment le demander ?
L’accès est ouvert aux responsables sécurité des entités suivies, sur demande et après vérification. Dans sa portée, un accès approuvé donne le détail contrôle par contrôle, la liste de ce qui reste à corriger, l’historique de chaque entité, une fiche PDF et l’analyse consolidée avec son plan d’action. La demande se fait sur cette page : demander un accès.
Que mesure le score de sécurité et comment est-il construit ?
Chaque contrôle porte un poids et une gravité. Le résultat d’une famille de contrôles est évalué selon trois niveaux : « Solide » à partir de 80 % des points, « Partiel » à partir de 40 %, « À renforcer » en dessous. Deux plafonds s’appliquent ensuite, quel que soit le total : un contrôle critique en échec ramène à « À renforcer », un contrôle critique partiel ou un contrôle majeur en échec interdit de dépasser « Partiel ». Le score global est la moyenne des sondes ayant produit un verdict, sur la même échelle. Ce qui n’a pas pu être mesuré reste « Non évalué » et n’entre pas dans cette moyenne. Pour en savoir plus : le détail des poids et des gravités, contrôle par contrôle.
Que sont les indicateurs complémentaires, affichés à titre informatif ?
Des mesures relevées à chaque analyse pour éclairer, sans noter : accès en IPv6 du site et de la messagerie, inscription dans la liste de préchargement HSTS des navigateurs, signature RPKI de la route vers le serveur, certificat des serveurs de messagerie ancré dans le DNS (DANE), traceurs publicitaires ou d’audience et polices Google appelés par la page d’accueil, opérateur et pays d’enregistrement des adresses du site et de la messagerie. Elles n’entrent dans aucun résultat : ces pratiques restent peu répandues ou dépendent de l’hébergeur, et une page lue sans exécuter de script ne dit pas si un traceur attend le consentement du visiteur. Le pays est celui sous lequel l’adresse est enregistrée, en général le siège de l’opérateur, pas l’emplacement du serveur. Le public en voit les parts par périmètre ; le détail par entité reste réservé à ses responsables sécurité.
À quelle fréquence ces données sont-elles mises à jour ?
Chaque périmètre est analysé sur une base mensuelle. La date exacte de la mesure affichée figure en tête des statistiques, plus haut sur cette page, et l’historique en conserve la trace mois après mois. Une correction apportée par une entité apparaît donc au passage suivant, pas le jour même.
Qu’est-ce qu’un fichier security.txt et à quoi sert-il ?
C’est un fichier texte publié à une adresse fixe, /.well-known/security.txt, normalisé par la RFC 9116. Il indique à qui signaler une faille de sécurité, dans quelle langue, et jusqu’à quelle date l’information est tenue à jour. Le publier revient à désigner, avant l’incident, qui traite les signalements – une attente de l’OFCS. Sans lui, la personne qui découvre un problème doit improviser : formulaire de contact générique, réseaux sociaux, ou renoncer. La bonne pratique est d’y indiquer une boîte générique relevée par plusieurs personnes plutôt que l’adresse d’une seule. Champs, politique de divulgation, obligations NIS2 et CRA, déploiement en six étapes : le guide complet de security.txt.
Qu’est-ce qu’un en-tête de sécurité HTTP ?
Une consigne que le serveur envoie au navigateur avec chaque page, et que le navigateur applique ensuite pour le compte du visiteur : rester en HTTPS (HSTS), n’exécuter que les scripts d’une liste déclarée (CSP), ne pas réinterpréter le type d’un fichier (nosniff), refuser l’affichage du site dans un cadre invisible (anti-clickjacking), limiter ce qui fuit vers les liens sortants (Referrer-Policy) ou l’accès aux fonctions du navigateur (Permissions-Policy). Ces consignes se règlent sur le serveur web, sans toucher au contenu du site. Rôle de chaque en-tête, priorités et déploiement sans casser le site : le guide complet des en-têtes de sécurité HTTP.
Comment un problème de certificat TLS est-il pris en compte ?
Le contrôle « Connexion chiffrée (HTTPS) » vérifie que le site répond en HTTPS avec un certificat accepté. Quand le certificat est refusé, la cause précise est indiquée avec la correction à apporter, et les autres en-têtes (HSTS, CSP, etc.) sont tout de même mesurés. Une chaîne de certificats incomplète compte comme « Partiel » : un navigateur de bureau complète souvent la chaîne de lui-même et affiche le site, mais d’autres clients (applications, outils de sécurité, certains mobiles) refusent la connexion. Un certificat expiré, émis pour un autre nom ou auto-signé compte comme un échec, car tous les navigateurs affichent alors un avertissement. Le détail de la négociation TLS (version du protocole, émetteur, date d’expiration à venir) n’est pas noté : un certificat se renouvelle aujourd’hui automatiquement toutes les quelques semaines, et surveiller son échéance produirait surtout des alertes qui se corrigent d’elles-mêmes. Un site qui ne répond pas du tout (nom introuvable, délai dépassé) reste « Non évalué » : une panne passagère ne se reproche pas. HTTPS, redirection et HSTS en détail : le guide des en-têtes de sécurité HTTP.
Que concerne la sécurité e-mail ?
Pas le contenu des messages, mais la capacité d’un tiers à écrire au nom du domaine. Les contrôles portent sur des enregistrements DNS publics, que chaque serveur de messagerie interroge déjà à la réception d’un courriel. Ils se publient dans la zone DNS, sans toucher au site web ni à la messagerie elle-même. Ils portent sur le domaine qui envoie réellement le courrier : quand les adresses d’une entité n’utilisent pas le domaine de son site (adresses au nom de la commune pour un site de service industriel, par exemple), c’est le domaine des adresses qui est mesuré. Les huit standards, les pièges courants et la trajectoire de p=none à p=reject : le guide complet de la sécurité des emails.
SPF, DMARC, DNSSEC : que fait chacun ?
SPF déclare quels serveurs ont le droit d’envoyer du courrier pour le domaine. DMARC indique au destinataire quoi faire des messages qui échouent à cette vérification – les laisser passer, les mettre en quarantaine ou les rejeter – et où envoyer les rapports : un SPF sans DMARC constate la fraude sans la bloquer. DNSSEC signe les réponses DNS pour qu’elles ne puissent pas être falsifiées en route, ce qui protège les deux premiers – un SPF parfait ne sert à rien si la réponse qui le porte peut être remplacée. S’y ajoutent CAA (quelles autorités peuvent émettre un certificat pour le domaine), MTA-STS et TLS-RPT (chiffrement du transport SMTP, et rapports d’échec). Le rôle de chacun, standard par standard : le guide de la sécurité des emails.
Pourquoi le DKIM n’est-il pas mesuré ?
DKIM compte, et sa signature est d’ailleurs utilisée par DMARC. Mais il n’est pas mesurable passivement : contrairement à SPF et DMARC, une clé DKIM se publie sous un sélecteur libre (default._domainkey, google._domainkey, selector1._domainkey…). Le vérifier supposerait de deviner ce nom, c’est-à-dire d’énumérer des sous-domaines – hors du mode passif des contrôles réalisés ici. Le fonctionnement de DKIM et son lien avec DMARC : le guide de la sécurité des emails.