En-têtes de sécurité HTTP : le guide pour protéger votre site sans écrire de code complexe

Mis à jour le 15 octobre 2026 · 9 minutes de lecture

Chaque fois qu'un navigateur charge votre site, le serveur lui envoie un petit paquet d'instructions invisibles appelé en-têtes HTTP. Parmi elles, une poignée d'en-têtes dites « de sécurité » dictent au navigateur comment se comporter face à votre page : accepter uniquement le HTTPS, refuser qu'elle soit affichée dans un cadre invisible, bloquer l'exécution d'un script non autorisé. Mal configurées ou absentes, elles laissent la porte ouverte à des attaques que ni un certificat SSL ni un pare-feu classique n'arrêtent.

Un en-tête HTTP, c'est quoi exactement ?

Avant même d'afficher la moindre image, le serveur de votre site et le navigateur du visiteur échangent une série de lignes de texte invisibles : les en-têtes. Elles précisent le type de contenu envoyé, sa taille, sa date de mise en cache... et, pour celles qui nous intéressent ici, des règles de sécurité que le navigateur doit respecter tant qu'il affiche votre page.

Contrairement à un pare-feu applicatif (WAF), qui filtre le trafic entrant avant qu'il n'atteigne votre serveur, les en-têtes de sécurité agissent dans l'autre sens : ils protègent le visiteur une fois que la page a déjà été chargée dans son navigateur. Les deux mécanismes se complètent, l'un ne remplace jamais l'autre.

Les en-têtes qui comptent vraiment pour un site web

1. Strict-Transport-Security (HSTS)

Cet en-tête force le navigateur à ne jamais charger votre site en HTTP, même si un visiteur tape l'adresse sans « https:// » ou clique sur un vieux lien. Sans HSTS, une fraction de trafic transite en clair le temps que la redirection HTTPS s'effectue, une fenêtre que des attaques dites « de l'homme du milieu » peuvent exploiter sur un réseau Wi-Fi public. Cet en-tête n'a de sens que si votre certificat SSL est valide et à jour en permanence.

2. Content-Security-Policy (CSP)

La CSP est l'en-tête le plus puissant et le plus technique : elle définit une liste blanche des sources autorisées à exécuter du JavaScript, charger des images ou des polices sur votre page. Bien configurée, elle neutralise la grande majorité des attaques par cross-site scripting (XSS), même si un formulaire mal filtré laisse passer un script malveillant : le navigateur refusera simplement de l'exécuter.

3. X-Frame-Options

Cet en-tête empêche votre site d'être affiché dans un cadre invisible (iframe) sur un autre site. Sans cette protection, un pirate peut superposer votre page de paiement ou de connexion sous une fausse interface et piéger vos visiteurs pour qu'ils cliquent sans le savoir sur vos propres boutons : c'est la technique du clickjacking.

4. X-Content-Type-Options

Avec la valeur nosniff, cet en-tête empêche le navigateur de « deviner » le type réel d'un fichier à la place de celui annoncé par le serveur. Sans elle, un fichier déguisé en image peut parfois être interprété et exécuté comme un script, ouvrant une brèche supplémentaire.

5. Referrer-Policy

Cet en-tête contrôle quelles informations sur la page d'origine sont transmises lorsqu'un visiteur clique sur un lien sortant. Une politique trop permissive peut exposer dans l'URL des données sensibles (identifiant de session, termes de recherche internes) à des sites tiers.

Pourquoi tant de sites ne les ont pas, ou mal configurés

Ces en-têtes ne s'affichent nulle part dans l'interface de votre site : aucun visiteur ne les voit, aucun badge ne les signale. Résultat, ils sont rarement une priorité au moment de la mise en ligne, surtout quand elle se fait dans l'urgence. Notre checklist de mise en ligne couvre les vérifications essentielles, mais la sécurité des en-têtes HTTP reste un angle mort pour la plupart des TPE et PME qui gèrent leur site sans développeur dédié.

L'autre raison, plus technique : une CSP ou un X-Frame-Options trop stricts peuvent casser des fonctionnalités légitimes (widget de chat, vidéo intégrée, script de paiement tiers). Par prudence, beaucoup d'hébergeurs laissent ces en-têtes désactivés par défaut plutôt que de risquer de rendre un site client inutilisable.

Comment vérifier l'état actuel de votre site

1. Un outil en ligne dédié. Des services gratuits comme securityheaders.com analysent votre page en quelques secondes et attribuent une note de A à F selon les en-têtes présents ou manquants.
2. Les outils de développement du navigateur. Ouvrez l'onglet « Réseau », rechargez votre page, cliquez sur la requête du document principal et consultez la section « En-têtes de réponse ».
3. Une vérification régulière. Un hébergeur qui change de configuration, une migration ou une mise à jour du serveur peuvent faire disparaître ces en-têtes sans que personne ne s'en rende compte pendant des mois.

Activer ces en-têtes selon votre situation

Sur WordPress, sans toucher au code

Des extensions de sécurité comme Wordfence proposent l'activation de plusieurs en-têtes de sécurité courants en quelques clics, sans ouvrir le moindre fichier. C'est l'option la plus sûre pour qui n'est pas développeur. Retrouvez l'ensemble des réflexes complémentaires dans notre checklist de sécurité WordPress.

Via un CDN ou un service en périphérie

La plupart des CDN permettent d'ajouter ou de forcer ces en-têtes au niveau de leur configuration, sans modifier votre serveur d'origine. C'est pratique si votre site utilise déjà un CDN pour la performance ou la protection, puisque l'essentiel du travail de sécurité se centralise au même endroit.

Directement sur le serveur (hébergement dédié ou VPS)

Si vous administrez votre serveur, ces en-têtes se configurent dans le fichier de configuration du serveur web (Apache, Nginx) ou via un fichier .htaccess. Procédez un en-tête à la fois, et testez votre site après chaque ajout plutôt que de tout activer en une seule fois.

Les précautions avant d'activer une CSP stricte

La Content-Security-Policy est, de loin, l'en-tête le plus susceptible de casser quelque chose si elle est mal réglée.

• Déployez-la d'abord en mode « report-only ». Cette variante journalise les blocages potentiels sans réellement les appliquer, ce qui permet d'observer l'impact avant de l'activer pour de vrai.
• Listez tous les scripts tiers en amont : outil d'analyse d'audience, widget de chat, module de paiement, police externe. Chacun doit être explicitement autorisé dans la politique, sous peine d'être silencieusement bloqué.
• Testez chaque page critique après activation, en particulier le formulaire de contact et le parcours de paiement, avec notre outil de test gratuit qui simule une visite externe en quelques secondes.

Un contrôle de sécurité qui s'ajoute, pas qui remplace

Les en-têtes de sécurité HTTP ne dispensent en rien des autres fondamentaux : un certificat SSL valide, des mises à jour CMS à jour, des sauvegardes récentes et, le cas échéant, un pare-feu applicatif. C'est une couche supplémentaire, peu coûteuse à mettre en place une fois comprise, qui réduit la surface d'attaque disponible sans rien changer à l'apparence de votre site.

Questions fréquentes