March Les en-têtes HTTP sont les héros méconnus de la communication web. Chaque fois que vous chargez une page web, diffusez une vidéo ou soumettez un formulaire, des dizaines d'en-têtes travaillent en coulisses pour que cela se produise. Ils transportent des métadonnées critiques sur les requêtes et les réponses, contrôlent le comportement de mise en cache, appliquent les politiques de sécurité et activent les fonctionnalités web modernes. Comprendre les en-têtes HTTP n'est plus réservé aux développeurs backend. Les ingénieurs frontend en ont besoin pour l'intégration d'API, les équipes DevOps s'appuient sur eux pour l'optimisation des performances, et les professionnels de la sécurité les utilisent pour protéger les applications contre les attaques. Ce guide détaille tout ce que vous devez savoir sur les en-têtes HTTP, des concepts de base aux implémentations de sécurité avancées. Table des matières Que sont les en-têtes HTTP ? En-têtes de requête : ce que les navigateurs envoient En-têtes de réponse : ce que les serveurs renvoient En-têtes de sécurité : protéger votre application En-têtes de mise en cache : optimisation des performances En-têtes CORS : partage de ressources cross-origin En-têtes personnalisés : quand et comment les utiliser Débogage des en-têtes HTTP Erreurs courantes et comment les éviter Meilleures pratiques pour les en-têtes HTTP Questions fréquemment posées Articles connexes Que sont les en-têtes HTTP ? Les en-têtes HTTP sont des paires clé-valeur envoyées entre les clients et les serveurs lors de la communication HTTP. Ils fournissent un contexte essentiel sur la requête ou la réponse, y compris le type de contenu, l'encodage, les informations d'authentification, les directives de mise en cache et les politiques de sécurité. Les en-têtes suivent un format simple : Header-Name: value. Chaque en-tête apparaît sur sa propre ligne, et une ligne vide sépare les en-têtes du corps du message. Alors que HTTP/1.1 utilise des en-têtes en texte brut, HTTP/2 et HTTP/3 les compressent en utilisant respectivement les algorithmes HPACK et QPACK. Les en-têtes se divisent en quatre catégories principales : En-têtes de requête - Envoyés par le client pour fournir des informations sur la requête ou le client lui-même En-têtes de réponse - Envoyés par le serveur pour fournir des informations sur la réponse En-têtes de représentation - Décrivent le format et l'encodage du corps du message En-têtes de charge utile - Contiennent des informations sur les données de charge utile, comme la longueur du contenu Les applications web modernes échangent généralement 20 à 40 en-têtes par cycle requête-réponse. Certains sont obligatoires (comme Host dans HTTP/1.1), tandis que d'autres sont facultatifs mais fortement recommandés pour la sécurité et les performances. Conseil pro : Utilisez l'onglet Réseau des DevTools de votre navigateur pour inspecter les en-têtes en temps réel. C'est inestimable pour déboguer les problèmes d'API et comprendre comment les services tiers communiquent avec votre application. En-têtes de requête : ce que les navigateurs envoient Les en-têtes de requête indiquent au serveur ce que le client veut et ce qu'il peut gérer. Ils incluent des informations sur les types de contenu acceptés, les langues préférées, les informations d'authentification et les capacités du client. Voici les en-têtes de requête les plus importants que vous rencontrerez : En-tête Objectif Exemple Host Spécifie le nom de domaine du serveur Host: example.com User-Agent Identifie le logiciel client User-Agent: Mozilla/5.0... Accept Types de médias que le client peut traiter Accept: application/json Accept-Language Langues préférées pour la réponse Accept-Language: en-US,en;q=0.9 Accept-Encoding Algorithmes de compression pris en charge Accept-Encoding: gzip, br Authorization Informations d'authentification Authorization: Bearer token123 Cookie Cookies stockés pour le domaine Cookie: session=abc123 Referer URL de la page précédente Referer: https://google.com Comprendre l'en-tête Accept L'en-tête Accept utilise des valeurs de qualité (valeurs q) pour indiquer la préférence lorsque plusieurs formats sont acceptables. Les valeurs vont de 0 à 1, 1 étant la priorité la plus élevée : Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Cela indique au serveur : "Je préfère HTML ou XHTML, mais j'accepterai XML avec une préférence de 90%, et tout autre format avec une préférence de 80%." Les serveurs utilisent cela pour effectuer une négociation de contenu et renvoyer le format le plus approprié. L'en-tête User-Agent L'en-tête User-Agent identifie le logiciel client, le système d'exploitation et le type d'appareil. Bien qu'utile pour les analyses et la diffusion de contenu spécifique à l'appareil, il est également notoirement peu fiable en raison de l'usurpation d'agent utilisateur. La meilleure pratique moderne consiste à utiliser la détection de fonctionnalités au lieu du reniflage d'agent utilisateur. Cependant, l'en-tête reste précieux pour la journalisation, le débogage et la détection des robots. Conseil rapide : Testez vos points de terminaison d'API avec différentes chaînes User-Agent pour vous assurer qu'ils ne se cassent pas pour les clients légitimes. Certains serveurs bloquent incorrectement les requêtes avec des agents utilisateurs inconnus. En-têtes de réponse : ce que les serveurs renvoient Les en-têtes de réponse fournissent des métadonnées sur la réponse du serveur, y compris le type de contenu, les instructions de mise en cache, les politiques de sécurité et les informations sur le serveur. Ils sont cruciaux pour un rendu de contenu approprié, l'optimisation des performances et la sécurité. Les en-têtes de réponse clés incluent : En-tête Objectif Exemple Content-Type Type de média du corps de la réponse Content-Type: text/html; charset=utf-8 Content-Length Taille du corps de la réponse en octets Content-Length: 1234 Content-Encoding Algorithme de compression utilisé Content-Encoding: gzip Set-Cookie Envoie des cookies au client Set-Cookie: id=a3; Secure; HttpOnly Location URL pour les redirections Location: https://example.com/new Server Informations sur le logiciel serveur Server: nginx/1.18.0 Date Date et heure d'envoi de la réponse Date: Mon, 31 Mar 2026 12:00:00 GMT ETag Identifiant unique pour la version de la ressource ETag: "33a64df551425fcc55e" Content-Type et encodage de caractères L'en-tête Content-Type est essentiel pour un rendu de contenu approprié. Il indique au navigateur comment interpréter le corps de la réponse. Incluez toujours l'encodage de caractères (généralement UTF-8) pour éviter les problèmes d'encodage : Content-Type: application/json; charset=utf-8 Content-Type: text/html; charset=utf-8 Content-Type: image/png Des en-têtes Content-Type manquants ou incorrects obligent les navigateurs à deviner le type de contenu (reniflage MIME), ce qui peut entraîner des vulnérabilités de sécurité et des problèmes de rendu. L'en-tête Set-Cookie L'en-tête Set-Cookie crée des cookies côté client. Les cookies modernes doivent toujours inclure des attributs de sécurité : Secure - Envoyer uniquement via des connexions HTTPS HttpOnly - Empêcher l'accès JavaScript pour réduire le risque XSS SameSite - Contrôler le comportement des cookies cross-site (Strict, Lax ou None) Max-Age ou Expires - Définir la durée de vie du cookie Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Max-Age=3600 En-têtes de sécurité : protéger votre application Les en-têtes de sécurité sont votre première ligne de défense contre les vulnérabilités web courantes. Ils demandent aux navigateurs d'appliquer des politiques de sécurité qui protègent les utilisateurs contre les attaques comme XSS, le détournement de clic et les attaques de l'homme du milieu. Chaque application de production devrait implémenter ces en-têtes de sécurité essentiels : Content-Security-Policy (CSP) CSP empêche les attaques XSS en contrôlant quelles ressources le navigateur peut charger. C'est l'un des en-têtes de sécurité les plus puissants mais nécessite une configuration minutieuse : Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com Commencez avec une politique restrictive et assouplissez-la progressivement selon les besoins. Utilisez Content-Security-Policy-Report-Only pour tester les politiques sans casser votre site. Strict-Transport-Security (HSTS) HSTS force les navigateurs à utiliser HTTPS pour toutes les futures requêtes vers votre domaine, empêchant les attaques de rétrogradation de protocole : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload La directive preload vous permet de soumettre votre domaine à la liste de préchargement HSTS, qui est codée en dur dans les navigateurs. Cela fournitle.com # Send custom headers curl -H "
Les en-têtes HTTP sont les héros méconnus de la communication web. Chaque fois que vous chargez une page web, diffusez une vidéo ou soumettez un formulaire, des dizaines d'en-têtes travaillent en coulisses pour que cela se produise. Ils transportent des métadonnées critiques sur les requêtes et les réponses, contrôlent le comportement de mise en cache, appliquent les politiques de sécurité et activent les fonctionnalités web modernes.
Comprendre les en-têtes HTTP n'est plus réservé aux développeurs backend. Les ingénieurs frontend en ont besoin pour l'intégration d'API, les équipes DevOps s'appuient sur eux pour l'optimisation des performances, et les professionnels de la sécurité les utilisent pour protéger les applications contre les attaques. Ce guide détaille tout ce que vous devez savoir sur les en-têtes HTTP, des concepts de base aux implémentations de sécurité avancées.
Les en-têtes HTTP sont des paires clé-valeur envoyées entre les clients et les serveurs lors de la communication HTTP. Ils fournissent un contexte essentiel sur la requête ou la réponse, y compris le type de contenu, l'encodage, les informations d'authentification, les directives de mise en cache et les politiques de sécurité.
Les en-têtes suivent un format simple : Header-Name: value. Chaque en-tête apparaît sur sa propre ligne, et une ligne vide sépare les en-têtes du corps du message. Alors que HTTP/1.1 utilise des en-têtes en texte brut, HTTP/2 et HTTP/3 les compressent en utilisant respectivement les algorithmes HPACK et QPACK.
Header-Name: value
Les en-têtes se divisent en quatre catégories principales :
Les applications web modernes échangent généralement 20 à 40 en-têtes par cycle requête-réponse. Certains sont obligatoires (comme Host dans HTTP/1.1), tandis que d'autres sont facultatifs mais fortement recommandés pour la sécurité et les performances.
Host
Conseil pro : Utilisez l'onglet Réseau des DevTools de votre navigateur pour inspecter les en-têtes en temps réel. C'est inestimable pour déboguer les problèmes d'API et comprendre comment les services tiers communiquent avec votre application.
Les en-têtes de requête indiquent au serveur ce que le client veut et ce qu'il peut gérer. Ils incluent des informations sur les types de contenu acceptés, les langues préférées, les informations d'authentification et les capacités du client.
Voici les en-têtes de requête les plus importants que vous rencontrerez :
Host: example.com
User-Agent
User-Agent: Mozilla/5.0...
Accept
Accept: application/json
Accept-Language
Accept-Language: en-US,en;q=0.9
Accept-Encoding
Accept-Encoding: gzip, br
Authorization
Authorization: Bearer token123
Cookie
Cookie: session=abc123
Referer
Referer: https://google.com
L'en-tête Accept utilise des valeurs de qualité (valeurs q) pour indiquer la préférence lorsque plusieurs formats sont acceptables. Les valeurs vont de 0 à 1, 1 étant la priorité la plus élevée :
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cela indique au serveur : "Je préfère HTML ou XHTML, mais j'accepterai XML avec une préférence de 90%, et tout autre format avec une préférence de 80%." Les serveurs utilisent cela pour effectuer une négociation de contenu et renvoyer le format le plus approprié.
L'en-tête User-Agent identifie le logiciel client, le système d'exploitation et le type d'appareil. Bien qu'utile pour les analyses et la diffusion de contenu spécifique à l'appareil, il est également notoirement peu fiable en raison de l'usurpation d'agent utilisateur.
La meilleure pratique moderne consiste à utiliser la détection de fonctionnalités au lieu du reniflage d'agent utilisateur. Cependant, l'en-tête reste précieux pour la journalisation, le débogage et la détection des robots.
Conseil rapide : Testez vos points de terminaison d'API avec différentes chaînes User-Agent pour vous assurer qu'ils ne se cassent pas pour les clients légitimes. Certains serveurs bloquent incorrectement les requêtes avec des agents utilisateurs inconnus.
Les en-têtes de réponse fournissent des métadonnées sur la réponse du serveur, y compris le type de contenu, les instructions de mise en cache, les politiques de sécurité et les informations sur le serveur. Ils sont cruciaux pour un rendu de contenu approprié, l'optimisation des performances et la sécurité.
Les en-têtes de réponse clés incluent :
Content-Type
Content-Type: text/html; charset=utf-8
Content-Length
Content-Length: 1234
Content-Encoding
Content-Encoding: gzip
Set-Cookie
Set-Cookie: id=a3; Secure; HttpOnly
Location
Location: https://example.com/new
Server
Server: nginx/1.18.0
Date
Date: Mon, 31 Mar 2026 12:00:00 GMT
ETag
ETag: "33a64df551425fcc55e"
L'en-tête Content-Type est essentiel pour un rendu de contenu approprié. Il indique au navigateur comment interpréter le corps de la réponse. Incluez toujours l'encodage de caractères (généralement UTF-8) pour éviter les problèmes d'encodage :
Content-Type: application/json; charset=utf-8 Content-Type: text/html; charset=utf-8 Content-Type: image/png
Des en-têtes Content-Type manquants ou incorrects obligent les navigateurs à deviner le type de contenu (reniflage MIME), ce qui peut entraîner des vulnérabilités de sécurité et des problèmes de rendu.
L'en-tête Set-Cookie crée des cookies côté client. Les cookies modernes doivent toujours inclure des attributs de sécurité :
Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Max-Age=3600
Les en-têtes de sécurité sont votre première ligne de défense contre les vulnérabilités web courantes. Ils demandent aux navigateurs d'appliquer des politiques de sécurité qui protègent les utilisateurs contre les attaques comme XSS, le détournement de clic et les attaques de l'homme du milieu.
Chaque application de production devrait implémenter ces en-têtes de sécurité essentiels :
CSP empêche les attaques XSS en contrôlant quelles ressources le navigateur peut charger. C'est l'un des en-têtes de sécurité les plus puissants mais nécessite une configuration minutieuse :
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com
Commencez avec une politique restrictive et assouplissez-la progressivement selon les besoins. Utilisez Content-Security-Policy-Report-Only pour tester les politiques sans casser votre site.
Content-Security-Policy-Report-Only
HSTS force les navigateurs à utiliser HTTPS pour toutes les futures requêtes vers votre domaine, empêchant les attaques de rétrogradation de protocole :
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
La directive preload vous permet de soumettre votre domaine à la liste de préchargement HSTS, qui est codée en dur dans les navigateurs. Cela fournitle.com # Send custom headers curl -H "
preload