Un entête de sécurité HTTP est une instruction que le serveur d’un site envoie au navigateur à chaque visite, avant même l’affichage de la page. Ces instructions sont invisibles pour l’internaute, mais elles décident de ce que le navigateur s’autorise à faire : forcer le chiffrement, refuser d’exécuter un script venu d’ailleurs, empêcher l’affichage de la page dans un cadre invisible. Cette page mesure les entêtes réellement envoyés par les sites officiels des 26 cantons suisses.
Aucun scan de vulnérabilités, aucune tentative d’exploitation. Ces contrôles se limitent à lire des informations déjà publiques — les mêmes qu’un navigateur ou un serveur de messagerie reçoit de toute façon en se connectant normalement à ce site.
Chargement de la carte…
Au 5 septembre 2026, 26 sites évalués sur Cantons suisses (Entêtes de sécurité) : 12 appliquent les bonnes pratiques (Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur).
- Solide12(46%)
- Partiel13(50%)
- À renforcer1(4%)
Vue nationale : 12 cantons sur 26 appliquent les bonnes pratiques (46 %). Le détail par canton est réservé aux responsables de sécurité (CISO) cantonaux et communaux.
À quoi servent les entêtes de sécurité ?
Ils comblent l’écart entre un site qui fonctionne et un site qui protège. Un site parfaitement accessible en HTTPS peut malgré tout autoriser n’importe quel script tiers, ou se laisser afficher dans une fenêtre invisible superposée à un faux bouton.
Chaque entête ferme une de ces portes. Aucun ne demande de modifier le site lui-même : ce sont des lignes de configuration du serveur web, ajoutées une fois et valables pour toutes les pages.
Le socle est acquis : tous les cantons redirigent vers HTTPS
C’est le résultat le plus encourageant de ce domaine. Un visiteur qui tape l’adresse d’un canton sans préciser https:// est systématiquement redirigé vers la version chiffrée du site, sur les 26 cantons sans exception.
Ce n’est pas un détail. Sans cette redirection, la première visite se ferait en clair, et l’entête HSTS — qui demande au navigateur de ne plus jamais utiliser que HTTPS — ne s’applique qu’après une première visite chiffrée réussie. La redirection est donc ce qui rend HSTS opérant.
Quels entêtes manquent le plus souvent ?
Deux manques dominent, et ils n’ont pas la même signification.
La Permissions-Policy, qui déclare quelles fonctions du navigateur — caméra, micro, géolocalisation — la page peut solliciter, est le plus fréquemment absente. C’est pourtant une seule ligne de configuration, sans effet de bord : fermer ce qui n’est pas utilisé ne casse rien.
La Content-Security-Policy, qui liste les scripts et ressources autorisés, manque à environ un site cantonal sur deux. C’est la mesure la plus efficace contre l’injection de code mais aussi la plus difficile à déployer : mal réglée, elle casse des fonctionnalités visibles.
Par où commencer, pour un canton ?
Par les entêtes qui ne peuvent rien casser : X-Content-Type-Options, Referrer-Policy et Permissions-Policy s’ajoutent sans risque et prennent effet immédiatement. Renforcer HSTS avec une durée d’au moins six mois vient ensuite. La Content-Security-Policy se traite en dernier, et progressivement.
Catalogue des contrôles
Détail technique de chaque contrôle ci-dessous. Sources : en-têtes HTTP, enregistrements DNS, fichier security.txt. Vérification automatique et périodique (hebdomadaire ou mensuelle selon le jeu de données) par DCOD, dans le cadre d'un observatoire public de la sécurité des sites suisses. Une question, ou besoin d'exclure un domaine ? hello@dcod.ch
Entêtes de sécurité
Mesures de durcissement annoncées par le site à chaque visite, qui protègent l'internaute dans son navigateur.
HEAD-HTTPSConnexion chiffrée disponible (HTTPS)CritiqueSans 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.
En savoir plus ↗HEAD-REDIRECTRedirection automatique vers HTTPSMajeurSans 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.
HEAD-HSTSNavigateur forcé à rester en HTTPS (HSTS)MajeurIndique 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.
HEAD-CSPListe des scripts et ressources autorisés (CSP)MineurLimite 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.
HEAD-NOSNIFFType de fichier non réinterprété par le navigateur (nosniff)MineurEmpê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 ».
En savoir plus ↗HEAD-FRAMEProtection contre l'affichage dans un cadre invisible (anti-clickjacking)MineurEmpê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.
En savoir plus ↗HEAD-REFERRERInformations limitées vers les liens sortants (Referrer-Policy)MineurContrô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.
HEAD-PERMISSIONSAccès aux fonctions du navigateur limité (Permissions-Policy)MineurDé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=() ».
En savoir plus ↗HEAD-VERSIONNuméro de version du logiciel non divulguéMineurUn 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).
En savoir plus ↗HEAD-COOKIESCookies protégés (Secure, HttpOnly, SameSite)MineurSans 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.
En savoir plus ↗Comment la situation évolue-t-elle ?
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| 2026-07 | 0 | 0 | 0 | 0 | 0 |
| 2026-08 | 11 | 14 | 1 | 0 | 26 |
| 2026-09 | 12 | 13 | 1 | 0 | 26 |
Questions fréquentes
Qu’est-ce qu’un entête de sécurité HTTP ?
C’est une instruction envoyée par le serveur au navigateur avant l’affichage de la page, qui restreint ce que le navigateur s’autorise à faire sur ce site : n’utiliser que des connexions chiffrées, n’exécuter que les scripts d’origines déclarées, refuser l’affichage dans un cadre. L’internaute ne les voit jamais, mais ils s’appliquent à chacune de ses visites.
Un site en HTTPS est-il déjà protégé ?
Pas complètement. HTTPS chiffre la connexion, mais ne dit rien de ce que la page a le droit de charger. Les entêtes de sécurité couvrent précisément ce que le chiffrement seul ne couvre pas.
Quelle différence entre la redirection vers HTTPS et l’entête HSTS ?
La redirection agit sur la visite en cours : elle renvoie vers la version chiffrée le visiteur arrivé sur l’adresse en clair. HSTS agit sur les visites suivantes : il demande au navigateur de n’utiliser que HTTPS pour ce site, sans même essayer la version en clair. Les deux sont complémentaires, et HSTS suppose la redirection pour être opérant dès la première visite.
Ajouter ces entêtes peut-il casser un site ?
Pour la plupart, non : X-Content-Type-Options, Referrer-Policy et Permissions-Policy sont sans effet de bord. La Content-Security-Policy fait exception, car elle peut bloquer des ressources légitimes si elle est mal réglée. C’est pourquoi elle se déploie d’abord en mode rapport seul.
Où ces entêtes se configurent-ils ?
Sur le serveur web — Apache, nginx, IIS — ou sur le service de diffusion placé devant le site. Ils ne dépendent ni du système de gestion de contenu ni du code des pages, ce qui les rend applicables à un site existant sans le refondre.
Qui peut consulter le résultat d’un canton en particulier ?
Les chiffres d’ensemble de cette page sont publics : combien de cantons appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. Le résultat détaillé d’un canton donné, en revanche, est réservé aux responsables de la sécurité des systèmes d’information (CISO) des cantons et des communes.
Un CISO qui obtient un accès voit en clair son canton et l’ensemble des communes de ce canton — de quoi agir chez lui — et les autres cantons en vue agrégée, de quoi se comparer. Le fichier security.txt fait exception et reste public sans condition : son objet même est d’être trouvé par qui cherche à signaler une faille.
Pourquoi le résultat détaillé d’un canton n’est-il pas public ?
Le résultat individuel de chaque entité est réservé aux responsables de sécurité (CISO) des cantons et des communes.
Qui peut obtenir un accès, et que voit-il de plus ?
Les responsables de sécurité des cantons et des communes suisses, sur demande et après validation manuelle. Un accès couvre tout un canton : le CISO cantonal et celui d’une commune de ce canton voient exactement la même chose, à savoir le détail du canton et de toutes ses communes. Les autres cantons restent en vue agrégée, ce qui permet la comparaison sans exposer personne.
Une zone grise sur la carte signifie-t-elle que l’entité n’est pas évaluée ?
Pas nécessairement. Le gris couvre deux situations, que la carte distingue au clic : soit la mesure n’a pas pu se faire — site injoignable, domaine qui ne résout plus — soit l’entité est bien évaluée mais son résultat individuel est réservé. Dans ce second cas, la carte affiche à la place le résultat agrégé de l’ensemble des cantons.