TL;DR : L’essentiel
- Un en-tête de sécurité HTTP est une consigne que le serveur envoie au navigateur avec chaque page. Le navigateur l’applique ensuite pour protéger le visiteur : rester en HTTPS, refuser les scripts non autorisés, bloquer l’affichage du site dans un cadre invisible, limiter les informations transmises aux sites tiers.
- Ces mesures se règlent sur le serveur web, le reverse proxy ou le CDN, sans modifier le contenu du site. C’est l’un des meilleurs rapports coût-efficacité de la sécurité web.
- Trois familles se distinguent : la sécurisation du transport (HTTPS, redirection, HSTS), le contrôle de ce que la page peut exécuter (CSP, nosniff, anti-clickjacking) et la limitation des fuites d’information (Referrer-Policy, Permissions-Policy, version du logiciel, cookies).
- La plupart des en-têtes se déploient en quelques heures. La politique de sécurité du contenu (CSP) est l’exception : elle demande un inventaire des scripts et une mise en place progressive.
- Les en-têtes ne corrigent aucune faille. Ils réduisent l’impact de celles qui existent ou existeront, et constituent un signal de maturité visible de l’extérieur par n’importe qui, y compris un attaquant.
Le site web public d’une organisation est souvent son actif informatique le plus exposé. Il est consulté par des milliers de visiteurs, s’appuie sur des scripts tiers (mesure d’audience, cartes, formulaires, chat) et reste accessible en permanence depuis n’importe où. Lorsqu’une faille est exploitée, qu’il s’agisse d’une injection de script, d’un détournement de clic ou d’une interception de session, c’est d’abord le visiteur qui en subit les conséquences.
Les en-têtes de sécurité HTTP permettent de faire du navigateur un allié. En quelques lignes de configuration, le serveur lui indique ce qu’il doit accepter et ce qu’il doit refuser. Ce guide explique à quoi sert chacun de ces en-têtes, comment ils s’articulent et quelles décisions ils impliquent pour un responsable sécurité ou un dirigeant. Il ne s’agit pas d’un manuel de configuration, mais d’une grille de compréhension et d’arbitrage.
Un en-tête de sécurité HTTP transforme le navigateur en agent de protection
Chaque fois qu’un navigateur demande une page, le serveur lui répond en deux temps : d’abord une série d’en-têtes, invisibles pour le visiteur, puis le contenu de la page. Ces en-têtes de sécurité HTTP décrivent la réponse (type de fichier, date, taille) et peuvent aussi transmettre des consignes de sécurité.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Un en-tête de sécurité HTTP est une consigne que le serveur envoie au navigateur avec chaque page, et que le navigateur applique ensuite pour le compte du visiteur. Il peut lui demander de ne jamais revenir en connexion non chiffrée, de n’exécuter que les scripts provenant de sources déclarées, de ne pas deviner le type d’un fichier, de refuser que le site soit affiché dans un cadre invisible ou de limiter ce qui est transmis aux sites tiers.
Leur intérêt tient en trois caractéristiques.
Ils se configurent sans toucher au site. Les en-têtes de sécurité HTTP se règlent sur le serveur web, le reverse proxy, le pare-feu applicatif ou le CDN. Le contenu, le code et le design du site restent inchangés.
Ils agissent là où l’organisation n’a plus la main. Une fois la page envoyée, elle s’exécute sur le poste du visiteur. Les en-têtes de sécurité HTTP sont le seul moyen de continuer à fixer des règles à cet endroit.
Ils sont visibles de l’extérieur. N’importe qui peut lire les en-têtes d’un site en quelques secondes. Leur présence ou leur absence renseigne donc sur la rigueur de l’organisation, ce qui intéresse autant un auditeur qu’un attaquant en phase de reconnaissance.
Trois familles d’en-têtes répondent à trois familles de risques
Les en-têtes de sécurité HTTP couramment recommandés se répartissent en trois familles, chacune répondant à une question distincte.
| Famille | Question | En-têtes et mesures |
|---|---|---|
| Transport | La connexion est-elle chiffrée, et le reste-t-elle ? | HTTPS, redirection vers HTTPS, HSTS |
| Exécution | Que la page a-t-elle le droit de charger et d’exécuter ? | Content-Security-Policy, X-Content-Type-Options, X-Frame-Options |
| Fuites d’information | Qu’est-ce que le site laisse échapper vers des tiers ou des attaquants ? | Referrer-Policy, Permissions-Policy, masquage de version, attributs des cookies |
HTTPS, redirection et HSTS verrouillent le transport des données
HTTPS est le prérequis de tout le reste
Sans HTTPS, tout ce qui circule entre le visiteur et le site peut être lu ou modifié en chemin : identifiants, données de formulaire, cookies de session. Un attaquant présent sur le même réseau Wi-Fi public, ou en position d’intercepter le trafic, peut aussi injecter du contenu dans les pages. Aucun autre en-tête n’a de valeur si la connexion elle-même n’est pas chiffrée, car un attaquant pourrait simplement les supprimer.
Avec la généralisation des certificats gratuits et automatisés, l’absence de HTTPS n’a plus aujourd’hui de justification technique ni économique.
La redirection ferme la porte en clair
Un visiteur qui tape une adresse sans préciser https:// arrive d’abord sur la version non chiffrée du site. Le serveur doit alors le rediriger immédiatement et de manière permanente vers la version chiffrée. Sans cette redirection, le premier échange reste en clair, et c’est précisément ce premier échange qu’un attaquant peut détourner.
La nuance entre redirection permanente et temporaire n’est pas un détail : une redirection temporaire incite le navigateur à retenter la version non chiffrée lors des visites suivantes.
HSTS supprime le premier échange en clair
La redirection a une faiblesse : elle intervient après une première requête non chiffrée. HSTS (HTTP Strict Transport Security), normalisé par l’IETF (RFC 6797), la comble. Cet en-tête indique au navigateur que, pendant une durée déterminée, il ne doit plus jamais contacter le site autrement qu’en HTTPS, même si le visiteur tape l’adresse sans préfixe ou suit un ancien lien en http://.
Deux paramètres méritent l’attention d’un décideur. La durée d’abord : une valeur d’un an est la référence ; une durée trop courte laisse la consigne expirer entre deux visites. L’extension aux sous-domaines ensuite (option includeSubDomains), qui renforce la protection mais impose que tous les sous-domaines, y compris les plus anciens ou les plus oubliés, soient accessibles en HTTPS.
Les navigateurs tiennent également une liste de préchargement HSTS : un domaine qui y est inscrit est protégé dès la toute première visite. L’inscription est une décision engageante. Elle couvre tous les sous-domaines, et le retrait de la liste prend des mois, le temps que les nouvelles versions des navigateurs soient diffusées.
CSP, nosniff et anti-clickjacking encadrent ce que la page exécute
CSP limite l’impact d’une injection de code
L’injection de script (XSS, pour cross-site scripting) reste l’une des vulnérabilités web les plus fréquentes. Elle permet à un attaquant de faire exécuter son propre code dans la page vue par le visiteur : vol de session, capture de saisie, redirection vers un faux formulaire de paiement.
La Content-Security-Policy (CSP) réduit fortement cet impact. Elle déclare au navigateur la liste des sources autorisées pour les scripts, les feuilles de style, les images ou les formulaires. Tout ce qui ne figure pas dans la liste est bloqué, y compris un script injecté par un attaquant.
C’est l’en-tête le plus puissant, et le plus difficile à déployer. Un site moderne charge souvent des dizaines de ressources externes : gestionnaire de balises, mesure d’audience, vidéos, polices, outils marketing. Une politique trop stricte casse des fonctionnalités ; une politique trop permissive, par exemple autorisant tous les scripts intégrés à la page (unsafe-inline), n’offre plus qu’une protection de façade.
La méthode éprouvée consiste à commencer en mode rapport (Content-Security-Policy-Report-Only) : le navigateur signale les violations sans rien bloquer. L’organisation observe, ajuste sa liste, puis bascule en mode appliqué. Comme pour DMARC dans la sécurité des emails, le risque est de rester indéfiniment en mode observation, qui ne protège personne.
Pour un décideur, la CSP pose une question de gouvernance plus large : qui décide des scripts tiers ajoutés au site ? Chaque outil marketing ajouté sans validation élargit la surface d’attaque et complique la politique. Le secteur des paiements l’a bien compris : depuis mars 2025, la norme PCI DSS 4.0 exige des commerçants un inventaire et une autorisation des scripts présents sur les pages de paiement, ainsi qu’une détection des modifications non autorisées de ces pages et de leurs en-têtes de sécurité.
nosniff empêche le navigateur de deviner
Les navigateurs ont longtemps tenté de deviner le type réel d’un fichier lorsque le serveur l’annonçait mal. Cette « bonne volonté » peut être exploitée : un fichier déposé comme image ou texte peut être interprété et exécuté comme un script. L’en-tête X-Content-Type-Options: nosniff interdit cette interprétation. Le navigateur s’en tient au type annoncé par le serveur. C’est une mesure simple, sans effet de bord sur un site correctement configuré.
L’anti-clickjacking empêche l’affichage dans un cadre invisible
Le clickjacking (détournement de clic) consiste à afficher le site légitime dans un cadre transparent, superposé à une page piégée. L’internaute croit cliquer sur un bouton anodin ; il valide en réalité une action sur le site légitime, où il est peut-être déjà connecté.
Deux mécanismes s’y opposent. L’en-tête historique X-Frame-Options interdit ou limite l’affichage du site dans un cadre. La directive frame-ancestors de la CSP fait de même avec plus de finesse et prévaut dans les navigateurs récents lorsque les deux sont présents. Le cumul des deux reste recommandé pour couvrir les navigateurs plus anciens.
Referrer-Policy, Permissions-Policy, version et cookies limitent les fuites de données
Referrer-Policy contrôle ce qui part vers les liens sortants
Lorsqu’un visiteur clique sur un lien vers un autre site, son navigateur transmet généralement l’adresse de la page d’origine. Cette adresse peut contenir des informations sensibles : identifiants de dossier, paramètres de recherche, jetons de réinitialisation de mot de passe. L’en-tête Referrer-Policy fixe ce qui est transmis. La valeur strict-origin-when-cross-origin, aujourd’hui adoptée par défaut par les principaux navigateurs, ne transmet que le nom du site aux tiers. La déclarer explicitement garantit un comportement identique quel que soit le navigateur.
Permissions-Policy ferme les fonctions inutiles du navigateur
Caméra, microphone, géolocalisation, paiement : les navigateurs modernes donnent aux pages web accès à de nombreuses fonctions. L’en-tête Permissions-Policy permet de déclarer celles que le site utilise réellement et de fermer toutes les autres. Si un script malveillant parvient à s’exécuter, il ne pourra pas solliciter ces fonctions. Pour un site institutionnel qui n’utilise ni caméra ni géolocalisation, la mesure est immédiate et sans contrepartie.
Masquer la version du logiciel prive l’attaquant d’un raccourci
De nombreux serveurs annoncent spontanément leur logiciel et sa version exacte (serveur web, langage de programmation). Cette information permet à un attaquant, ou à un outil automatisé, de rechercher directement les failles connues de cette version. Masquer la version ne corrige rien, et ne remplace pas l’application des correctifs. Mais cela oblige l’attaquant à travailler davantage et empêche un site d’apparaître dans les recherches automatisées de versions vulnérables.
Les attributs des cookies protègent les sessions
Les cookies transportent souvent l’identité de session du visiteur. Trois attributs, transmis dans l’en-tête qui les crée, en conditionnent la sécurité :
- Secure : le cookie n’est jamais envoyé sur une connexion non chiffrée ;
- HttpOnly : le cookie n’est pas lisible par un script, ce qui limite l’impact d’une injection ;
- SameSite : le cookie n’est pas envoyé lors des requêtes initiées par d’autres sites, ce qui réduit le risque de falsification de requête (CSRF).
Un cookie de session sans ces attributs est une cible de choix pour qui cherche à usurper la connexion d’un utilisateur.
Certains en-têtes sont devenus obsolètes
La liste des en-têtes recommandés évolue. Plusieurs mécanismes largement cités dans d’anciens guides doivent aujourd’hui être abandonnés.
X-XSS-Protection activait un filtre anti-injection intégré aux anciens navigateurs. Ce filtre a été retiré des navigateurs modernes, et il pouvait lui-même introduire des vulnérabilités. La recommandation actuelle est de ne plus l’utiliser ou de le désactiver explicitement ; la CSP a pris le relais.
Public-Key-Pins (HPKP) permettait d’épingler les certificats attendus pour un site. Le risque de rendre un site inaccessible par erreur était tel que les navigateurs l’ont abandonné.
Expect-CT servait à exiger la transparence des certificats, désormais imposée par défaut par les navigateurs. Il n’a plus d’utilité.
La présence de ces en-têtes sur un site n’est pas grave en soi, mais elle signale souvent une configuration copiée d’un ancien guide et jamais revue.
Les en-têtes ne remplacent aucune autre mesure
Les en-têtes de sécurité HTTP sont une couche de défense supplémentaire, pas une solution. Quatre limites doivent être gardées à l’esprit.
Ils réduisent l’impact des failles, ils ne les corrigent pas. Une CSP limite ce qu’un script injecté peut faire ; elle ne supprime pas la vulnérabilité qui a permis l’injection. Le développement sécurisé, la gestion des correctifs et les tests restent indispensables.
Ils ne protègent que les visiteurs dont le navigateur les applique. Un navigateur obsolète ou un outil automatisé peut les ignorer.
Ils doivent couvrir toutes les pages. Un en-tête configuré sur la page d’accueil mais absent des pages de connexion, de formulaire ou des sous-domaines laisse les zones les plus sensibles sans protection.
Ils ne disent rien du reste de l’infrastructure. Un site irréprochable dans ses en-têtes peut reposer sur un serveur mal corrigé, une configuration TLS faible ou une application vulnérable.
Déployer les en-têtes de sécurité en six étapes
La plupart des en-têtes de sécurité HTTP se déploient en une journée. L’essentiel de l’effort porte sur la CSP et sur l’organisation qui garantit que la configuration reste en place.
- Inventorier les sites exposés, y compris ceux hébergés par des prestataires, les sous-domaines et les sites de campagne.
- Traiter les mesures rapides : HTTPS partout, redirection permanente, HSTS d’un an, nosniff, anti-clickjacking, Referrer-Policy, Permissions-Policy, masquage de version et attributs des cookies.
- Centraliser la configuration là où c’est possible (reverse proxy, CDN, pare-feu applicatif), pour appliquer les mêmes règles à tous les sites et à toutes les pages.
- Déployer la CSP progressivement : mode rapport, analyse des violations, réduction des scripts tiers, puis mode appliqué.
- Inscrire les exigences dans les contrats avec les agences web et hébergeurs, pour que chaque nouveau site soit livré avec ces en-têtes et que leur maintien soit vérifiable.
- Contrôler dans la durée : une mise à jour du serveur, un changement de CDN ou une refonte suffit à faire disparaître un en-tête sans que personne ne s’en aperçoive.
Questions fréquentes sur les en-têtes de sécurité HTTP
Qu’est-ce qu’un en-tête de sécurité HTTP ?
C’est une instruction transmise par le serveur au navigateur avec chaque page, que le navigateur applique ensuite pour protéger le visiteur. Elle peut imposer le maintien en HTTPS (HSTS), restreindre les scripts autorisés (CSP), interdire la réinterprétation du type d’un fichier (nosniff), bloquer l’affichage du site dans un cadre invisible, limiter les informations transmises aux sites tiers (Referrer-Policy) ou l’accès aux fonctions du navigateur (Permissions-Policy). Ces instructions se configurent sur le serveur web, sans modifier le contenu du site.
Quels en-têtes de sécurité faut-il prioriser ?
HTTPS, la redirection permanente vers HTTPS et HSTS viennent en premier, car ils conditionnent l’efficacité de tous les autres. Suivent les mesures simples et sans effet de bord : nosniff, anti-clickjacking, Referrer-Policy, Permissions-Policy, masquage de version et attributs des cookies. La CSP, plus puissante mais plus exigeante, se déploie ensuite de manière progressive.
Pourquoi la CSP est-elle si difficile à déployer ?
Parce qu’elle oblige à déclarer toutes les sources de scripts et de ressources utilisées par le site. Sur un site qui accumule les outils tiers (mesure d’audience, marketing, vidéos, chat), cet inventaire est long et chaque oubli casse une fonctionnalité. Le mode rapport permet d’observer les violations avant de bloquer quoi que ce soit.
Les en-têtes de sécurité remplacent-ils un pare-feu applicatif ou les correctifs ?
Non. Les en-têtes réduisent l’impact d’une faille côté navigateur ; ils ne la corrigent pas et ne bloquent pas les attaques visant directement le serveur. Ils complètent le développement sécurisé, la gestion des correctifs et le pare-feu applicatif, qui peut d’ailleurs servir à les appliquer de manière centralisée.
Faut-il inscrire son domaine dans la liste de préchargement HSTS ?
C’est la protection la plus complète, puisque le site est protégé dès la première visite. Mais la décision engage durablement : tous les sous-domaines doivent être accessibles en HTTPS, et un retrait de la liste prend plusieurs mois. Elle est à réserver aux organisations qui maîtrisent l’inventaire complet de leurs sous-domaines.
L’en-tête X-XSS-Protection est-il encore utile ?
Non. Le filtre qu’il activait a été retiré des navigateurs modernes et pouvait introduire ses propres vulnérabilités. La recommandation actuelle est de ne plus l’utiliser, ou de le désactiver explicitement, et de s’appuyer sur la CSP.
Qui doit configurer les en-têtes lorsque le site est géré par un prestataire ?
L’organisation reste responsable de la sécurité de ses sites, même lorsqu’ils sont développés ou hébergés par un tiers. Les en-têtes attendus doivent figurer dans le cahier des charges et le contrat, avec un moyen de vérifier qu’ils restent en place après chaque mise à jour.
Pour approfondir le sujet
Projet OWASP Secure Headers | Fondation OWASP
Le projet OWASP Secure Headers (OSHP) décrit les en-têtes de réponse HTTP que votre application peut utiliser pour améliorer sa sécurité. Lire la suite
En-têtes HTTP – Fiches récapitulatives OWASP
Site web regroupant toutes les fiches récapitulatives du projet. Lire la suite
En-tête Content-Security-Policy (CSP) – HTTP
L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateur·ice·s d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Lire la suite
En-tête Strict-Transport-Security – HTTP
L'en-tête de réponse HTTP Strict-Transport-Security (HSTS) indique aux navigateurs que l'hôte ne doit être accessible que via HTTPS et que toute tentative d'accès ultérieure via HTTP sera automatiquement redirigée vers HTTPS. De plus, lors des connexions ultérieures à l'hôte, le… Lire la suite
RFC 6797 : Sécurité stricte du transport HTTP (HSTS) | Éditeur de RFC
Cette spécification définit un mécanisme permettant aux sites web de se déclarer accessibles uniquement via des connexions sécurisées et/ou aux utilisateurs de configurer leur navigateur pour interagir avec ces sites uniquement via des connexions sécurisées. Cette politique globale est appelée… Lire la suite
Zéro paywall. Zéro pub.
DCOD reste en accès libre grâce à vos contributions. Chaque café compte.
