Sécurité des sites web des communes suisses

Sans point de contact publié, une personne qui découvre une faille ne sait pas à qui l'annoncer et renonce souvent.

Publier un fichier texte à l'adresse /.well-known/security.txt du site.

Seul champ obligatoire de la RFC 9116 : c'est lui qui porte l'adresse ou le formulaire de signalement.

Ajouter une ligne « Contact: mailto:security@exemple.ch » (répéter la ligne pour plusieurs contacts, ne pas la renommer).

Également obligatoire : il indique jusqu'à quand l'information de contact est considérée comme à jour.

Ajouter « Expires: » avec une date ISO 8601 future (par exemple dans un an) et penser à la renouveler.

Un fichier servi par une seule des deux variantes reste invisible pour qui arrive par l'autre.

Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre.

Sans HTTPS, tout ce qui circule entre le visiteur et le site peut être lu ou modifié en chemin. Ce contrôle vérifie que le site répond correctement en HTTPS, pas la redirection depuis l'ancienne adresse en http://.

Installer un certificat (Let's Encrypt est gratuit et automatisable) et servir le site en HTTPS.

Sans redirection, un visiteur qui tape l'adresse sans https:// reçoit d'abord une réponse en clair : HSTS, qui suppose déjà une première visite réussie en HTTPS, ne peut s'appliquer qu'après.

Configurer le serveur pour rediriger (301 ou 302) toute requête HTTP vers l'adresse HTTPS équivalente, dès le premier saut.

• Le port 80 répond directement (le contenu est servi en clair) au lieu de rediriger vers l'adresse HTTPS.
• Une redirection a bien lieu, mais pas vers une adresse en https:// (ou sans indiquer de destination) : le premier échange reste en clair malgré tout.

Indique au navigateur de n'utiliser que HTTPS pour ce site, y compris si le visiteur tape l'adresse sans https://.

Ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (6 mois minimum recommandés).

• Aucun en-tête Strict-Transport-Security n'est envoyé : le navigateur n'est jamais forcé à rester en HTTPS pour ce site.
• L'en-tête est présent mais sans durée (max-age) exploitable : le navigateur ne peut pas retenir la consigne.
• La durée annoncée (max-age) est inférieure à 6 mois : la mesure existe, mais une visite un peu espacée suffit à la faire expirer.

Limite les scripts et ressources que la page a le droit de charger, ce qui réduit fortement l'impact d'une injection de code.

Définir une politique, en commençant en mode rapport (Content-Security-Policy-Report-Only) pour vérifier qu'elle ne casse rien.

• Aucune politique de sécurité de contenu n'est envoyée, ni en mode appliqué ni en mode rapport.
• La politique publiée est en mode « rapport seul » (Content-Security-Policy-Report-Only) : elle observe les violations sans encore en bloquer aucune.

Empêche le navigateur de deviner le type d'un fichier, et donc d'exécuter comme script un contenu qui n'en est pas un.

Ajouter l'en-tête « X-Content-Type-Options: nosniff ».

Empêche un site tiers d'afficher les pages du site dans un cadre invisible pour faire cliquer l'internaute à son insu.

Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP.

Contrôle les informations d'origine transmises aux sites tiers lorsqu'un visiteur suit un lien sortant.

Ajouter « Referrer-Policy: strict-origin-when-cross-origin ».

• Aucun en-tête Referrer-Policy n'est envoyé : le navigateur applique son comportement par défaut, qui varie d'un navigateur à l'autre.
• La politique publiée est « unsafe-url » : l'adresse complète (chemin compris) est transmise à chaque site tiers lié, y compris depuis une page en HTTPS vers un lien en HTTP.

Déclare quelles fonctionnalités du navigateur (caméra, micro, géolocalisation) la page peut solliciter.

Ajouter une politique fermant ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ».

Un numéro de version précis (Apache/2.4.41, PHP/7.4.3…) permet à un attaquant de cibler directement les failles connues de cette version, sans avoir à les chercher.

Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (souvent ServerTokens/ServerSignature sous Apache, expose_php sous PHP).

Sans l'attribut Secure, un cookie peut être intercepté si le site est un jour accédé en clair. Sans HttpOnly, un script injecté peut le lire. Sans SameSite, il est envoyé vers des sites tiers qui n'en ont pas besoin.

Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site.

Déclare quels serveurs ont le droit d'envoyer du courrier au nom du domaine. Sans lui, n'importe qui peut se faire passer pour l'entité auprès des administrés.

Publier un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés. Terminer par -all (rejet) : sans cela, l'enregistrement n'a pas d'effet contraignant réel (~all ne fait que marquer, ?all ne fait rien), et « +all » autorise au contraire le monde entier. Un seul enregistrement SPF par domaine : plusieurs annulent la protection.

• Aucun enregistrement SPF n'est publié pour ce domaine.
• Deux enregistrements SPF (ou plus) sont publiés en même temps : selon la RFC 7208, les serveurs destinataires doivent alors ignorer complètement la vérification (permerror), comme s'il n'y en avait aucun.
• L'enregistrement publié se termine par « +all », qui autorise explicitement n'importe quel serveur à envoyer du courrier au nom du domaine – une autorisation générale, pas une protection incomplète.
• L'enregistrement publié se termine par « ~all » (marquage) plutôt que « -all » (rejet) : purement indicatif, un serveur destinataire a le droit de délivrer quand même le courriel frauduleux normalement. Le domaine reste donc usurpable en pratique.
• L'enregistrement publié ne se termine ni par « -all » ni par « ~all » (et n'utilise pas non plus « redirect= ») : il ne restreint donc aucun expéditeur.

Indique aux serveurs destinataires quoi faire des courriels qui échouent aux vérifications, et permet de recevoir des rapports sur les tentatives d'usurpation.

Publier un TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » pour observer, puis durcir vers p=reject (p=quarantine reste une étape intermédiaire : le courriel frauduleux atteint quand même la boîte du destinataire). Une fois à p=reject, viser pct=100 (ou l'omettre, valeur par défaut) et sp=reject si le domaine a des sous-domaines. Un seul enregistrement DMARC par domaine : plusieurs font ignorer la politique par les destinataires.

• Aucun enregistrement DMARC n'est publié sur _dmarc.<domaine>.
• Deux enregistrements DMARC (ou plus) sont publiés en même temps : selon la RFC 7489, les destinataires doivent alors ignorer la politique (permerror), comme s'il n'y en avait aucune.
• Un enregistrement DMARC existe, mais sans balise « p= » exploitable (none, quarantine ou reject) : les destinataires ne savent pas quoi faire des courriels non conformes.
• La politique publiée est « p=none » : c'est l'étape de surveillance recommandée avant de durcir, mais elle ne bloque ni ne marque encore aucun courriel frauduleux.
• La politique publiée est « p=quarantine » : les courriels frauduleux sont déviés vers les indésirables plutôt que rejetés – une réduction réelle du risque, mais le message atteint quand même la boîte du destinataire et reste à sa merci.
• La politique « p=reject » n'est appliquée qu'à une fraction des courriels frauduleux (balise « pct= » inférieure à 100) : le reste retombe sur une politique plus faible, comme si aucun rejet n'était configuré pour cette part-là.
• Le domaine lui-même est bien protégé (« p=reject »), mais ses sous-domaines le sont moins (balise « sp= » plus faible) : un courriel usurpant un sous-domaine (ex. newsletter.<domaine>) peut échapper au rejet.

Signe les réponses DNS du domaine, ce qui empêche de rediriger silencieusement les visiteurs ou le courrier vers un serveur illégitime.

Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple case à cocher), puis publier l'enregistrement DS chez le registraire.