Vérification des en-têtes HTTP

Que sont les en-têtes HTTP ?

Les en-têtes HTTP sont des métadonnées envoyées avec chaque requête et chaque réponse HTTP échangées entre le navigateur et le serveur web. Ils contiennent des informations essentielles sur la sécurité, la mise en cache, la compression et la manière dont le navigateur doit traiter le contenu. Avec notre outil gratuit de vérification des en-têtes HTTP, vous analysez tous les en-têtes de n'importe quel site web et vous voyez immédiatement les risques de sécurité possibles et les pistes d'optimisation.

Les en-têtes sont invisibles pour les visiteurs, mais ils jouent un rôle crucial dans le fonctionnement du web moderne. Chaque fois que votre navigateur demande un site web, des dizaines d'en-têtes sont échangés. Le navigateur envoie des en-têtes de requête (comme User-Agent, Accept-Language) et le serveur répond avec des en-têtes de réponse (comme Content-Type, Cache-Control, les en-têtes de sécurité). Cet échange détermine la façon dont le contenu est affiché, mis en cache et sécurisé.

Il existe plusieurs catégories d'en-têtes : les en-têtes de sécurité, qui protègent contre les attaques, les en-têtes de cache, qui améliorent les performances, les en-têtes de contenu, qui précisent le type et l'encodage, et les en-têtes CORS, qui encadrent les requêtes multi-origines (cross-origin). Une vérification des en-têtes HTTP approfondie vous donne une vue sur toutes ces catégories et montre où des améliorations sont possibles.

Pourquoi les en-têtes de sécurité sont-ils importants ?

Les en-têtes de sécurité constituent une ligne de défense cruciale contre les attaques web courantes. Ils ajoutent une couche de sécurité supplémentaire au-dessus du code de votre application et protègent à la fois votre site web et vos visiteurs. Même avec un code parfaitement sécurisé, l'absence d'en-têtes de sécurité peut vous rendre vulnérable aux attaques. Notre outil de vérification des en-têtes HTTP contrôle tous les en-têtes de sécurité essentiels et vous donne des recommandations concrètes.

Les en-têtes de sécurité protègent votre site web et vos visiteurs contre :

• Les attaques XSS (Cross-Site Scripting) : avec Content-Security-Policy (CSP), vous empêchez l'exécution de scripts malveillants
• Le clickjacking : avec X-Frame-Options, vous vous protégez contre les iframes invisibles qui interceptent les clics
• Les attaques de l'homme du milieu (man-in-the-middle) : avec HSTS, vous imposez des connexions HTTPS chiffrées
• Les attaques par MIME sniffing : avec X-Content-Type-Options, vous empêchez les navigateurs de deviner le type de contenu
• Les attaques multi-origines : avec les en-têtes COOP et CORP, vous isolez votre site web des autres origines
• Les fuites de referrer : avec Referrer-Policy, vous contrôlez les informations transmises
• L'abus des fonctions du navigateur : avec Permissions-Policy, vous limitez l'accès aux API sensibles du navigateur

Sans les bons en-têtes de sécurité, votre site web est vulnérable aux attaques, même si le code lui-même est sûr. Les chercheurs en sécurité et les testeurs d'intrusion examinent toujours en premier les en-têtes HTTP pour repérer les failles. Les grandes entreprises technologiques comme Google, Facebook et Microsoft appliquent des politiques strictes en matière d'en-têtes de sécurité. Avec notre outil, vous effectuez les mêmes contrôles qu'un audit de sécurité professionnel.

Les principaux en-têtes de sécurité expliqués

Strict-Transport-Security (HSTS) : cet en-tête oblige les navigateurs à se connecter à votre site web uniquement via HTTPS. Il empêche les attaquants de rétrograder les utilisateurs vers un trafic HTTP non sécurisé (attaques par SSL stripping). Dès qu'un navigateur a reçu cet en-tête, il convertit automatiquement toutes les requêtes HTTP en HTTPS pendant la durée indiquée, même si l'utilisateur saisit explicitement http://. Configuration recommandée : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. La valeur max-age indique pendant combien de temps (en secondes) le navigateur doit s'en souvenir, includeSubDomains applique la règle à tous les sous-domaines et preload rend votre site éligible à la liste de préchargement HSTS (HSTS preload list) des navigateurs.

Content-Security-Policy (CSP) : l'en-tête de sécurité le plus efficace contre les attaques XSS. CSP définit les sources (scripts, feuilles de style, images, polices) que le navigateur peut charger et exécuter. Cela empêche l'exécution de scripts malveillants injectés, même si un attaquant parvient à injecter du code dans votre HTML. Une CSP de base peut ressembler à ceci : Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'. Pour une sécurité maximale, évitez 'unsafe-inline' et utilisez des nonces ou des hachages.

X-Frame-Options : empêche le chargement de votre site web dans un iframe, ce qui contre les attaques par clickjacking. Lors d'un clickjacking, un attaquant place votre site dans un iframe invisible au-dessus d'une fausse interface, de sorte que les utilisateurs effectuent sans le savoir des actions sur votre site. Utilisez X-Frame-Options: DENY pour bloquer tout affichage dans un frame, ou X-Frame-Options: SAMEORIGIN pour ne l'autoriser que depuis votre propre domaine. Pour les navigateurs modernes, Content-Security-Policy: frame-ancestors 'none' est une solution plus souple.

X-Content-Type-Options : empêche le MIME sniffing en indiquant au navigateur de respecter le type de contenu déclaré. Les navigateurs essaient parfois de « deviner » le type de contenu lorsqu'il n'est pas clair, ce qui peut causer des problèmes de sécurité. Un fichier text/plain peut par exemple être interprété comme du JavaScript s'il contient du code exécutable. Utilisez toujours X-Content-Type-Options: nosniff pour l'éviter.

Tous les en-têtes de sécurité en un coup d'œil

Voici un aperçu complet de tous les en-têtes de sécurité importants que vous pouvez mettre en place pour une protection maximale. Notre outil de vérification des en-têtes HTTP les contrôle tous :

Content-Security-Policy en détail

Content-Security-Policy (CSP) est l'en-tête de sécurité le plus complexe, mais aussi le plus efficace. Une CSP bien configurée peut éliminer presque totalement les attaques XSS. CSP fonctionne avec des directives qui définissent, pour chaque type de contenu, les sources autorisées.

Principales directives CSP :

• default-src : politique par défaut pour tous les types de ressources. Les autres directives en héritent.
• script-src : définit les sources JavaScript qui peuvent être chargées et exécutées. Essentiel pour la protection contre les attaques XSS.
• style-src : contrôle les feuilles de style et les styles inline autorisés.
• img-src : définit les sources depuis lesquelles les images peuvent être chargées.
• font-src : contrôle les sources autorisées pour les polices.
• connect-src : limite les URL accessibles via fetch, XMLHttpRequest et WebSocket.
• frame-src : définit les URL qui peuvent être chargées dans des frames (comparable à X-Frame-Options, mais pour le contenu intégré).
• media-src : contrôle les sources des éléments audio et vidéo.
• object-src : définit les sources autorisées pour les éléments <object>, <embed> et <applet>.

Valeurs de source CSP : chaque directive accepte une liste de sources autorisées. Vous pouvez utiliser : 'self' (votre propre domaine), 'none' (rien n'est autorisé), des domaines précis comme https://cdn.example.com, 'unsafe-inline' (scripts et styles inline, non sûr), 'unsafe-eval' (la fonction eval(), non sûr) ou des nonces/hachages pour des scripts inline précis.

Nonces et hachages : pour une sécurité maximale, évitez 'unsafe-inline' et utilisez plutôt des nonces ou des hachages. Un nonce est une valeur aléatoire unique que vous générez à chaque requête et que vous ajoutez à la fois dans l'en-tête CSP et dans la balise script : Content-Security-Policy: script-src 'nonce-abc123' et <script nonce="abc123">. Les hachages sont des empreintes SHA-256/384/512 du contenu exact du script : script-src 'sha256-xyz...'.

Report-URI et signalement : CSP peut signaler les violations à un point de terminaison : report-uri /csp-report, ou avec la directive plus moderne report-to. Vous pouvez ainsi surveiller si du contenu légitime est bloqué et s'il y a des tentatives d'attaque. Commencez toujours par Content-Security-Policy-Report-Only pour tester sans bloquer de contenu.

En-têtes de performance et de cache

Outre la sécurité, notre vérification des en-têtes HTTP analyse aussi les en-têtes de performance et de cache, essentiels pour des sites web rapides :

• Content-Encoding : vérifie si la compression est active. Les sites web modernes utilisent la compression gzip ou Brotli pour réduire la taille des fichiers texte (HTML, CSS, JavaScript) de 70 à 80 %. Content-Encoding: br (Brotli) compresse mieux que gzip, mais n'est pas pris en charge par tous les navigateurs. Content-Encoding: gzip est le choix sûr qui fonctionne partout. Sans compression, les pages se chargent beaucoup plus lentement, surtout sur les connexions mobiles.
• Cache-Control : analyse les réglages de cache pour des performances optimales. Cet en-tête détermine pendant combien de temps les navigateurs et les CDN peuvent mettre le contenu en cache. Pour les ressources statiques (CSS, JS, images), utilisez Cache-Control: public, max-age=31536000, immutable pour une mise en cache d'un an. Pour le contenu dynamique, utilisez Cache-Control: private, max-age=0, must-revalidate. Une bonne stratégie de cache peut réduire la charge de votre serveur de 90 % et améliorer fortement les temps de chargement.
• ETag : vérifie si la validation du cache est activée. Un ETag est un identifiant unique pour une version précise d'une ressource. Lorsqu'un navigateur a du contenu en cache, il envoie l'ETag dans un en-tête If-None-Match. Si le contenu n'a pas changé, le serveur répond avec 304 Not Modified sans renvoyer le contenu complet, ce qui économise de la bande passante.
• Vary : indique quels en-têtes de requête influencent la mise en cache. Vary: Accept-Encoding indique aux caches de stocker à la fois les versions compressées et non compressées. Vary: User-Agent met en cache des versions différentes par type de navigateur (souvent inutile et peu efficace). Pour les sites responsive modernes, Vary: Accept-Encoding suffit généralement.
• Last-Modified : indique quand le contenu a été modifié pour la dernière fois et fonctionne avec If-Modified-Since pour la validation du cache.

De bons en-têtes de cache peuvent rendre votre site web nettement plus rapide, réduire la charge du serveur et faire fortement baisser les coûts de bande passante. Pour un hébergement WordPress ou d'autres plateformes CMS, de bons en-têtes de cache sont indispensables aux performances.

Comment améliorer votre score de sécurité ?

Après une vérification des en-têtes HTTP, notre outil donne un score par catégorie et des recommandations concrètes. Vous pouvez mettre en place les en-têtes de sécurité de plusieurs façons :

1. Configuration du serveur web : la méthode la plus efficace consiste à définir les en-têtes au niveau du serveur web. Pour Apache (.htaccess), Nginx ou IIS, vous pouvez ajouter des en-têtes qui s'appliquent à toutes les requêtes. C'est plus rapide que des en-têtes au niveau de l'application, car le serveur web les ajoute directement sans exécuter PHP ni d'autre code applicatif. Avec un serveur VPS, vous avez le contrôle total de la configuration du serveur web.

2. Code de l'application : en PHP, Node.js, Python ou dans d'autres langages, vous pouvez ajouter des en-têtes par programmation. Cela offre plus de souplesse (par exemple des politiques CSP différentes par page), mais c'est un peu plus lent. Pour les sites WordPress, vous pouvez ajouter des en-têtes via functions.php ou des extensions de sécurité.

3. Niveau CDN/proxy : des services comme Cloudflare, AWS CloudFront ou d'autres CDN peuvent ajouter ou modifier des en-têtes. C'est idéal pour les sites qui utilisent déjà un CDN. Cloudflare propose par exemple des « Transform Rules » simples pour ajouter des en-têtes.

4. Extensions CMS : pour WordPress, il existe d'excellentes extensions de sécurité qui configurent automatiquement les en-têtes, comme Really Simple SSL, Security Headers ou All In One WP Security. Ces extensions proposent une interface conviviale, sans que vous ayez à modifier des fichiers de configuration.

Commencez par les en-têtes essentiels (HSTS, CSP, X-Frame-Options, X-Content-Type-Options), puis ajoutez d'autres en-têtes de sécurité comme Referrer-Policy et Permissions-Policy. Testez toujours soigneusement après l'ajout d'en-têtes : CSP en particulier peut bloquer des fonctions légitimes si elle est configurée de façon trop stricte.

En-têtes HTTP pour WordPress

Pour les sites WordPress, les en-têtes HTTP demandent une attention particulière. Par défaut, WordPress n'envoie que très peu d'en-têtes de sécurité : vous devez donc les ajouter vous-même. Il existe trois méthodes pour ajouter des en-têtes à WordPress :

Méthode 1 : via .htaccess (Apache). Si votre site tourne sous Apache (la plupart des offres d'hébergement web), ajoutez ces règles au fichier .htaccess à la racine de WordPress :

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
</IfModule>

Remarque : cette CSP est relativement permissive avec 'unsafe-inline' et 'unsafe-eval', car WordPress et de nombreuses extensions utilisent des scripts inline. Pour une CSP plus stricte, vous devrez peut-être adapter le code des extensions.

Méthode 2 : via wp-config.php. Vous pouvez ajouter des en-têtes dans wp-config.php (ajoutez ceci avant la ligne « That's all, stop editing ! ») :

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Frame-Options: SAMEORIGIN');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');

Méthode 3 : via functions.php. Ajoutez cette fonction dans le fichier functions.php de votre thème (ou dans une extension personnalisée) :

function add_security_headers() {
  header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
}
add_action('send_headers', 'add_security_headers');

Extensions WordPress : pour une configuration plus conviviale, vous pouvez utiliser des extensions comme « HTTP Headers » (de Dimitar Ivanov) ou « Security Headers », qui proposent une interface graphique pour configurer les en-têtes. Really Simple SSL ajoute aussi automatiquement quelques en-têtes de sécurité après son activation. Pour un hébergement WordPress chez Theory7, vous pouvez aussi contacter le support pour obtenir de l'aide sur la configuration des en-têtes.

En-têtes HTTP pour Apache et Nginx

La configuration des en-têtes HTTP diffère entre les serveurs web Apache et Nginx. Les deux sont des options performantes, mais leur syntaxe est différente.

Configuration Apache (.htaccess ou httpd.conf) :

Pour Apache, utilisez le module mod_headers. Ajoutez ceci dans le fichier .htaccess ou dans la configuration de votre hôte virtuel :

<IfModule mod_headers.c>
  # Security headers
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'"

  # Performance headers
  Header always set Cache-Control "public, max-age=31536000, immutable" "expr=%{REQUEST_URI} =~ m#\.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$#"
  Header always set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#\.(html|php)$#"
</IfModule>

Vérifiez que mod_headers est activé : a2enmod headers, puis redémarrez Apache.

Configuration Nginx (nginx.conf ou bloc server) :

Pour Nginx, ajoutez les en-têtes dans votre bloc server ou dans le contexte location :

server {
  # Security headers
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'" always;

  # Static assets caching
  location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    expires 1y;
  }

  # Dynamic content
  location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
}

Après chaque modification, testez la configuration avec nginx -t et rechargez-la avec nginx -s reload. Le mot-clé always garantit que les en-têtes sont aussi ajoutés aux réponses d'erreur (4xx, 5xx).

Pour les deux serveurs web : après l'ajout d'en-têtes, testez soigneusement avec notre outil de vérification des en-têtes HTTP et vérifiez que votre site fonctionne toujours correctement.

Codes de réponse HTTP

Les codes de réponse HTTP (codes d'état) sont envoyés via les en-têtes et indiquent si une requête a abouti. Notre outil affiche le code d'état à chaque vérification. Codes courants :

Le code d'état figure sur la première ligne des en-têtes de réponse, par exemple HTTP/1.1 200 OK. Pour les redirections (301/302), la nouvelle adresse est indiquée dans l'en-tête Location. En cas d'erreur, les serveurs envoient souvent un en-tête Content-Type: text/html avec une page d'erreur. Des codes d'état corrects sont essentiels pour le SEO : utilisez 301 pour les redirections permanentes et veillez à ce que les pages supprimées renvoient 404 (et non 200).

Les en-têtes CORS expliqués

Les en-têtes CORS (Cross-Origin Resource Sharing) déterminent si un site web peut charger des ressources depuis un autre domaine. Par défaut, les navigateurs bloquent les requêtes multi-origines pour des raisons de sécurité. Les en-têtes CORS donnent une autorisation explicite.

Access-Control-Allow-Origin : le principal en-tête CORS. Il définit quelles origines ont accès à vos ressources. Access-Control-Allow-Origin: * autorise toutes les origines (dangereux pour les API sensibles), Access-Control-Allow-Origin: https://example.com n'autorise que ce domaine précis. Pour les API appelées depuis le navigateur (par exemple des requêtes AJAX), cet en-tête doit être correctement défini.

Access-Control-Allow-Methods : indique les méthodes HTTP autorisées : Access-Control-Allow-Methods: GET, POST, PUT, DELETE. Par défaut, seules GET et POST sont autorisées pour les requêtes simples.

Access-Control-Allow-Headers : précise les en-têtes de requête que le client peut envoyer : Access-Control-Allow-Headers: Content-Type, Authorization. Nécessaire pour les en-têtes personnalisés ou les jetons d'authentification.

Access-Control-Allow-Credentials : détermine si les cookies et les en-têtes d'authentification peuvent être envoyés : Access-Control-Allow-Credentials: true. Si cette valeur est true, Access-Control-Allow-Origin ne peut pas être *.

Requêtes de pré-vérification (preflight) : pour les requêtes « non simples » (par exemple PUT, DELETE ou des en-têtes personnalisés), le navigateur envoie d'abord une requête OPTIONS (preflight) pour vérifier si la requête est autorisée. Le serveur doit alors répondre avec les bons en-têtes CORS. Une réponse preflight ressemble à ceci :

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

L'en-tête Access-Control-Max-Age indique pendant combien de temps (en secondes) la réponse preflight peut être mise en cache, ce qui améliore les performances. Pour les API web et les points de terminaison sécurisés par SSL, des en-têtes CORS corrects sont indispensables.

En-têtes HTTP/2 et HTTP/3

Les protocoles modernes HTTP/2 et HTTP/3 traitent les en-têtes plus efficacement que HTTP/1.1, mais les noms et les valeurs des en-têtes restent en grande partie les mêmes. Notre vérification des en-têtes HTTP fonctionne avec toutes les versions de HTTP.

Améliorations de HTTP/2 : HTTP/2 introduit la compression d'en-têtes HPACK, qui réduit nettement la taille des en-têtes. Les en-têtes sont encodés avec un codage de Huffman et une table statique/dynamique des en-têtes fréquents. Cela économise de la bande passante, car Content-Type: text/html est par exemple encodé en un seul octet au lieu de 24 octets. HTTP/2 prend aussi en charge le multiplexage : plusieurs requêtes partagent la même connexion, ce qui réduit encore la surcharge liée aux en-têtes.

Pseudo-en-têtes dans HTTP/2 : HTTP/2 utilise des pseudo-en-têtes spéciaux qui commencent par un deux-points : :method, :path, :scheme, :authority. Ils remplacent la première ligne des requêtes HTTP/1.1 (GET /path HTTP/1.1). Pour les développeurs, ils sont généralement invisibles, car les bibliothèques s'en chargent automatiquement.

HTTP/3 et QUIC : HTTP/3 s'appuie sur HTTP/2, mais utilise QUIC au lieu de TCP comme protocole de transport. Les en-têtes fonctionnent comme dans HTTP/2, mais QPACK (une version améliorée de HPACK) offre une compression encore meilleure et résiste mieux à la perte de paquets. HTTP/3 utilise UDP au lieu de TCP, ce qui réduit la latence, car aucune poignée de main TCP (handshake) n'est nécessaire.

Server Push (HTTP/2) : HTTP/2 prend en charge le server push : le serveur envoie des ressources de façon proactive avant que le navigateur ne les demande. Cela fonctionne via l'en-tête Link avec rel=preload : Link: </style.css>; rel=preload; as=style. Le server push est expérimental et n'est pas pris en charge par tous les CDN. HTTP/3 a abandonné le push au profit des Early Hints (HTTP 103).

Points d'attention pour la migration : lorsque vous passez à HTTP/2 ou HTTP/3, vos en-têtes de sécurité, de cache et CORS continuent de fonctionner exactement de la même façon. Les protocoles sont rétrocompatibles au niveau des en-têtes. Vous devez en revanche configurer correctement vos certificats SSL/TLS, car HTTP/2 et HTTP/3 exigent HTTPS. Pour un VPS ou des serveurs dédiés, vous devez utiliser nginx 1.9.5+ ou Apache 2.4.17+ pour la prise en charge de HTTP/2.

Vérifiez avec notre outil quel protocole votre site utilise : la version HTTP est affichée dans les en-têtes de réponse. HTTP/2 et HTTP/3 peuvent améliorer les temps de chargement de 20 à 50 %, surtout pour les sites comportant de nombreuses petites ressources.