Les headers HTTP — un oubli pour beaucoup de sites

La sécurité web est souvent réduite au HTTPS ou à la robustesse des mots de passe. Pourtant, une couche essentielle est régulièrement négligée : les headers HTTP. Ces en-têtes, envoyés par le serveur au navigateur à chaque requête, définissent la manière dont le navigateur doit se comporter avec le contenu du site. Bien configurés, ils constituent une première ligne de défense efficace contre de nombreuses attaques courantes, tout en améliorant la fiabilité technique et la crédibilité du site.

Les sept headers essentiels

Strict-Transport-Security (HSTS)

Force le navigateur à utiliser exclusivement HTTPS pour toutes les connexions. Paramétrage recommandé :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Le paramètre preload mérite une attention particulière : il permet d’inscrire le domaine dans la liste HSTS préconfigurée des navigateurs, ce qui renforce la protection dès la première visite, avant même le premier échange HTTP. Mais c’est un engagement fort et quasi-irréversible. Une fois soumis à cette liste, en sortir peut prendre plusieurs mois. Il ne faut l’activer que si HTTPS est parfaitement stable sur l’ensemble des sous-domaines concernés.

Content-Security-Policy (CSP)

Définit précisément quelles sources de scripts, d’images, de styles ou d’autres ressources sont autorisées à être chargées. Il est conseillé de commencer en mode Report-Only pour identifier les blocages potentiels avant de passer en mode bloquant.

C’est le header le plus puissant contre les attaques XSS, mais aussi le plus délicat à maintenir. Chaque nouveau script tiers, chaque mise à jour d’outil analytics ou de tag manager peut potentiellement la casser. La CSP n’est pas une configuration ponctuelle : c’est un travail continu qui exige rigueur et suivi dans le temps.

Le meta-framework Astro 6 a récemment introduit une gestion native de la CSP pour faciliter sa mise en place et son maintien, une initiative à saluer qui pourrait inspirer d’autres outils à suivre le pas.

X-Frame-Options

Empêche le site d’être affiché dans une iframe par un site tiers. Paramétrage recommandé : SAMEORIGIN. Protège contre le clickjacking, une technique qui consiste à superposer une interface invisible sur la page légitime pour tromper l’utilisateur.

À noter : ce header est en voie de dépréciation. La directive frame-ancestors de la CSP le remplace désormais en offrant un contrôle plus fin. Il reste utile pour assurer la compatibilité avec les navigateurs anciens, mais les deux approches doivent idéalement être combinées.

X-Content-Type-Options

Empêche le navigateur de deviner le type de contenu et l’oblige à respecter le type MIME déclaré par le serveur. Paramétrage : nosniff. Réduit le risque d’exécution de ressources mal interprétées par le navigateur, notamment des scripts déguisés en images ou en fichiers texte.

Referrer-Policy

Contrôle quelles informations sont transmises au site cible lors d’une navigation. Paramétrage recommandé : strict-origin-when-cross-origin.

Cette valeur est déjà le comportement par défaut des navigateurs modernes depuis quelques années. Ce n’est pas une raison de l’omettre et l’expliciter dans les headers garantit un comportement cohérent quel que soit le client, mais il est utile de savoir qu’on aligne ici la configuration sur une pratique déjà largement adoptée.

Permissions-Policy

Limite l’accès des pages et des scripts aux fonctionnalités du navigateur : caméra, microphone, géolocalisation, etc. Exemple :

Permissions-Policy: geolocation=(), camera=(), microphone=()

Attention : désactiver en bloc toutes les fonctionnalités n’est pas toujours adapté. Un site qui utilise la géolocalisation pour afficher une carte, ou le microphone pour un outil vocal, se cassera lui-même. La Permissions-Policy doit être calibrée selon les besoins réels du site, en ne désactivant que ce qui n’est effectivement pas utilisé.

Cache-Control

Souvent omis, ce header mérite pourtant d’y figurer. Une mauvaise configuration du cache peut exposer des données sensibles via des proxies intermédiaires ou des navigateurs partagés. Sur les pages contenant des informations personnelles ou des sessions utilisateur, no-store empêche toute mise en cache, private la restreint au seul navigateur de l’utilisateur.

Pourquoi ces headers sont-ils encore souvent absents ?

Malgré leur importance, la majorité des sites web ne disposent toujours pas des principaux headers de sécurité. Plusieurs raisons l’expliquent.

Ils ne sont pas activés par défaut. La plupart des serveurs, CMS et frameworks n’appliquent pas ces headers automatiquement, afin de préserver la compatibilité maximale. Sans configuration spécifique, ils sont simplement inexistants.

La CSP est perçue comme complexe. Une Content-Security-Policy mal configurée peut bloquer des scripts tiers légitimes et provoquer des dysfonctionnements visibles en production. Par prudence, beaucoup de projets préfèrent ne pas l’activer plutôt que de risquer de casser des fonctionnalités.

Ils ont une faible visibilité côté métier. Contrairement au HTTPS ou aux performances, les headers de sécurité sont invisibles pour l’utilisateur final et rarement mentionnés dans les cahiers des charges. Ils passent souvent au second plan lors de la mise en production, faute de prescription claire.

Leur configuration est répartie sur plusieurs couches techniques. Selon l’architecture du site, les headers peuvent être définis au niveau du serveur, du CDN, du reverse proxy ou de l’application elle-même. Cette multiplicité de points de configuration entraîne fréquemment des oublis ou des incohérences difficiles à détecter.

La culture sécurité reste inégale. Dans beaucoup d’organisations, la sécurité est abordée après la mise en ligne, alors qu’elle devrait être intégrée dès la conception. Les headers de sécurité ne font pas exception.

Où et comment les configurer ?

Trois niveaux possibles selon l’architecture du projet :

• Côté serveur (nginx, Apache), c’est la solution la plus performante, appliquée en amont de toute logique applicative. Idéal pour les headers statiques qui ne varient pas selon la route.
• Côté application (Next.js, WordPress, autres frameworks), cela permet des réglages dynamiques ou des exceptions par route, utile pour la CSP notamment.
• Via des plugins ou modules, une solution pratique pour les hébergements mutualisés ou les environnements sans accès direct au serveur.

Quelques repères pour la mise en place : configurer les headers critiques côté serveur en priorité ; gérer la CSP côté application pour pouvoir tester et ajuster sans risquer de casser le site en production ; ne pas activer preload sur le HSTS sans avoir vérifié la stabilité HTTPS de l’ensemble des sous-domaines.

Tester sa configuration

Deux outils en ligne permettent d’auditer les headers d’un site en quelques secondes : SecurityHeaders.com et Mozilla Observatory. Tous les deux identifient les headers manquants et donnent une note globale.

Mozilla Observatory est nettement plus exigeant et atteindre la note maximale n’est pas aisé (personnellement je plafonne à B+). N’hésitez pas à tester des sites grand public dessus, les résultats sont parfois surprenants.

Ces sept headers constituent aujourd’hui un standard incontournable pour tout site professionnel. Leur mise en place est accessible, leur impact concret, et les outils pour vérifier leur présence sont gratuits et immédiats. Il n’y a guère de raison de continuer à les ignorer.