Les headers HTTP : les grands oubliés de la sécurité web

Lorsqu’on parle de sécurité web, le réflexe est souvent de penser 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.

Quels sont les headers HTTP essentiels et leur rôle ?

Strict-Transport-Security (HSTS)

Force le navigateur à utiliser exclusivement HTTPS pour toutes les connexions. Paramétrage recommandé : 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 des navigateurs, ce qui renforce la protection dès la première visite. Mais c’est un engagement fort et quasi-irréversible, une fois soumis à cette liste, il est très difficile d’en sortir, avec des délais pouvant atteindre 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 contenus 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 de plugin ou d’outil analytics 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.

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 permettant de tromper l’utilisateur en superposant une interface invisible sur la page légitime.
À noter : ce header est en voie de dépréciation. La directive frame-ancestors de la CSP le remplace désormais et offre 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é. Paramétrage : nosniff. Réduit le risque d’exécution de contenus mal interprétés par le navigateur.

Referrer-Policy

Contrôle quelles informations sont transmises au site cible lors de la navigation. Paramétrage recommandé : strict-origin-when-cross-origin.
À préciser : 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, l’expliciter dans les headers garantit un comportement cohérent quel que soit le navigateur, 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 sites et des scripts à certaines fonctionnalités du navigateur : caméra, microphone, géolocalisation, etc. Exemple : geolocation=(), camera=(), microphone=().
Attention cependant : 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 oublié dans les discussions sur la sécurité, 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, il est recommandé d’utiliser no-store pour empêcher toute mise en cache, ou private pour restreindre le cache au seul navigateur de l’utilisateur.

Pourquoi ces headers sont-ils encore souvent absents ?

Malgré leur importance, de nombreux sites web ne disposent toujours pas des principaux headers de sécurité. Plusieurs raisons expliquent cette situation.

1. 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 avec tous les scripts et extensions. Sans configuration spécifique, ils sont tout simplement inexistants.
2. Certaines directives sont perçues comme complexes, notamment la CSP.
   Une Content-Security-Policy mal configurée peut bloquer des scripts tiers légitimes : analytics, tag manager, bibliothèques externes, plugins, et provoquer des dysfonctionnements visibles. Par prudence, beaucoup de projets préfèrent ne pas l’activer plutôt que de risquer de casser des fonctionnalités en production.
3. 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 ainsi souvent au second plan lors de la mise en production, faute de prescription claire.
4. 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.
5. La culture sécurité reste inégale sur de nombreux projets.
   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 : leur mise en place correcte est pourtant aujourd’hui un standard incontournable pour tout site professionnel.

Comment et où paramétrer les headers HTTP ?

Ces headers peuvent être configurés à différents niveaux selon l’architecture du projet : côté serveur (Apache / Nginx), solution la plus performante, appliquée en amont de toute logique applicative ; côté application (WordPress, Next.js, autres frameworks), ce qui permet des réglages dynamiques ou des exceptions par route ; ou via des plugins et modules, solution pratique pour les hébergements mutualisés ou les environnements sans accès direct au serveur.

Quelques bonnes pratiques à retenir : commencer par configurer les headers critiques côté serveur pour des raisons de performance et de cohérence ; gérer la CSP côté application afin de pouvoir tester et ajuster sans risquer de casser le site ; ne pas activer preload sur le HSTS sans avoir vérifié la stabilité HTTPS de l’ensemble des sous-domaines ; adapter la Permissions-Policy aux fonctionnalités réellement utilisées plutôt que de tout désactiver par défaut.

Vous pouvez tester régulièrement la configuration avec des outils dédiés comme SecurityHeaders.com ou Mozilla Observatory. Ces deux outils sont très utiles et permettent d’identifier les headers manquant en un seul coup d’œil. L’outils Mozilla semble beaucoup plus exigeant en terme de contrôle, le niveau maximum de conformité n’est pas simple à atteindre (je plafonne à B+ pour l’instant). N’hésitez pas à tester divers sites grand public dessus, les résultats sont parfois surprenants…

---

Les headers HTTP sont trop souvent laissés de côté, alors que leur mise en place est à la fois accessible et particulièrement efficace pour renforcer la sécurité d’un site et améliorer sa fiabilité technique. Certains demandent un calibrage attentif, la CSP et le HSTS avec preload en tête, mais tous méritent d’être traités avec soin dès le lancement d’un projet. Quelle que soit l’architecture retenue, ces sept headers constituent aujourd’hui un élément indispensable de tout site web professionnel et sécurisé.