Les headers de sécurité HTTP sont une couche de protection invisible pour le visiteur mais redoutable pour les attaquants, qui s’ajoute en quelques lignes au fichier .htaccess ou à la configuration nginx d’un site WordPress. Ils donnent au navigateur des instructions explicites sur ce qu’il a le droit de faire avec votre site : depuis quels domaines il peut charger des scripts, s’il peut être affiché dans une iframe, s’il doit forcer HTTPS sur toutes les requêtes. Mal configurés ou absents, ces headers laissent passer des attaques par injection de script (XSS), du clickjacking ou du downgrade vers HTTP non chiffré. Bien configurés, ils transforment le navigateur lui-même en pare-feu côté client. Chez Propuls’Lead, nous activons systématiquement six headers de sécurité sur tous les sites WordPress que nous mettons en production, parce qu’ils ferment des classes entières d’attaques pour un effort de configuration de quinze minutes.
Comprendre le rôle des headers HTTP dans la sécurité d’un site WordPress
Quand un navigateur charge une page WordPress, le serveur lui répond avec deux blocs : le corps HTML de la page et un ensemble de headers HTTP qui décrivent la réponse. La plupart de ces headers sont techniques (type de contenu, encodage, cache), mais une famille spécifique sert uniquement à la sécurité. Ces headers indiquent au navigateur les règles strictes qu’il doit appliquer pour protéger le visiteur.
Six headers de sécurité couvrent la majorité des besoins d’un site WordPress de PME. Content-Security-Policy (CSP) restreint les sources autorisées de scripts, styles, images et iframes. Strict-Transport-Security (HSTS) force l’usage exclusif de HTTPS pour toutes les visites futures. X-Frame-Options empêche le site d’être affiché dans une iframe sur un autre domaine, ce qui bloque les attaques par clickjacking. X-Content-Type-Options empêche le navigateur d’interpréter un fichier dans un format différent de celui annoncé par le serveur. Referrer-Policy contrôle quelles informations de provenance sont envoyées aux sites tiers. Permissions-Policy (anciennement Feature-Policy) restreint l’accès aux fonctionnalités sensibles du navigateur comme la géolocalisation ou la caméra.
Ces six headers se vérifient en quelques secondes via l’outil gratuit securityheaders.com qui attribue une note de A+ à F au site analysé. Sur les sites WordPress fraîchement installés, la note initiale est typiquement F ou D, parce qu’aucun de ces headers n’est activé par défaut. Notre article sur sécuriser son site WordPress avec les 10 actions qui bloquent 99 % des attaques revient sur l’ensemble des mesures de durcissement qui complètent ces headers.
Configurer Content-Security-Policy pour bloquer les injections de script
Content-Security-Policy est le plus puissant des headers de sécurité et aussi le plus délicat à régler. Son rôle est de lister explicitement les sources autorisées pour chaque type de ressource : scripts JavaScript, feuilles de style, images, polices, iframes, requêtes AJAX. Toute ressource provenant d’une source non listée est bloquée par le navigateur, même si elle a été injectée dans le HTML par une faille XSS.
Une politique CSP minimale pour un site WordPress ressemble à : default-src ‘self’; script-src ‘self’ ‘unsafe-inline’ https://www.googletagmanager.com; style-src ‘self’ ‘unsafe-inline’ https://fonts.googleapis.com; img-src ‘self’ data: https:; font-src ‘self’ https://fonts.gstatic.com; frame-src ‘self’ https://www.youtube.com. Cette politique autorise les ressources hébergées sur le site lui-même, les scripts Google Tag Manager, les polices Google Fonts, les images HTTPS, et les iframes YouTube. Toute autre source est bloquée.
Le piège classique de CSP est le mode trop restrictif qui casse le site : un plugin charge un script depuis un CDN non listé, et le plugin cesse de fonctionner sans message d’erreur visible. Pour éviter ce piège, déployer CSP en deux temps : d’abord en mode Report-Only pendant deux semaines, qui logue les violations sans bloquer, puis en mode bloquant après ajustement de la politique. La directive report-uri permet de rediriger les rapports vers un endpoint d’analyse. Notre article sur WordPress et permissions fichiers, les réglages serveur qui protègent votre site revient sur les autres couches de sécurité serveur qui se combinent avec CSP.
Activer HSTS, X-Frame-Options et les headers complémentaires
Strict-Transport-Security force le navigateur à utiliser exclusivement HTTPS pour toutes les requêtes vers votre domaine pendant une durée définie (typiquement un an). La syntaxe recommandée est Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Le drapeau preload permet l’inscription du domaine dans la liste HSTS embarquée dans Chrome, Firefox et Safari, ce qui force HTTPS dès la première visite, sans même une requête HTTP préalable.
X-Frame-Options bloque l’affichage du site dans une iframe sur un autre domaine, ce qui prévient les attaques de clickjacking où un site malveillant superpose votre interface de connexion à des éléments invisibles pour piéger les clics. Deux valeurs sont disponibles : DENY interdit toute iframe (recommandé pour la majorité des sites WordPress) et SAMEORIGIN autorise les iframes uniquement sur le même domaine (utile si vous embarquez votre propre site dans une autre page).
X-Content-Type-Options: nosniff empêche le navigateur de deviner le type d’un fichier en analysant son contenu, ce qui ferme une classe d’attaques par injection de script déguisé en image ou en CSS. Referrer-Policy: strict-origin-when-cross-origin limite l’envoi du referrer aux requêtes vers le même domaine, ce qui protège la vie privée des visiteurs et évite la fuite d’URL contenant des paramètres sensibles. Permissions-Policy bloque l’accès aux fonctionnalités sensibles non utilisées par votre site : camera=(), microphone=(), geolocation=(), interest-cohort=(). Notre article sur SSL HTTPS WordPress, pourquoi et comment passer à la connexion sécurisée revient sur les fondations HTTPS qui rendent HSTS pertinent.
Implémenter les headers via .htaccess, nginx ou un plugin WordPress
L’implémentation pratique se fait par trois voies selon votre configuration serveur. Voie 1 : modification du fichier .htaccess à la racine du site WordPress pour les serveurs Apache (cas de la majorité des hébergements mutualisés français comme OVH, o2switch, Infomaniak). Six lignes Header always set suffisent pour activer les six headers d’un coup. Cette voie est la plus accessible aux non-techniciens et survit aux mises à jour WordPress.
Voie 2 : modification du fichier de configuration nginx pour les serveurs nginx (VPS ou hébergement managé orienté performance). Les directives add_header s’ajoutent dans le bloc server { } de la configuration du site. Cette voie nécessite un accès SSH et un rechargement du service nginx après modification. Un test de configuration via nginx -t avant rechargement évite de casser le serveur en cas d’erreur de syntaxe.
Voie 3 : installation d’un plugin WordPress dédié comme HTTP Headers ou Really Simple SSL Pro qui ajoute une interface graphique pour configurer les headers depuis l’administration. Cette voie convient aux entrepreneurs sans accès serveur ou peu à l’aise avec les fichiers de configuration. L’inconvénient : un plugin supplémentaire à maintenir et à mettre à jour, alors que les voies 1 et 2 ne demandent aucune maintenance ultérieure. Notre article sur protéger sa page de connexion WordPress contre les attaques par force brute revient sur les protections complémentaires qui se combinent avec les headers HTTP.
Tester, mesurer et industrialiser dans la méthodologie PROPULSE
Une fois les headers déployés, la vérification est immédiate via trois outils gratuits. Securityheaders.com attribue une note globale et liste les headers manquants ou mal configurés. Mozilla Observatory complète l’analyse avec des recommandations détaillées et un score sur 100. SSL Labs analyse la qualité de la configuration TLS qui sous-tend HSTS. L’objectif est d’atteindre A+ sur securityheaders.com et A+ sur SSL Labs, ce qui correspond à une configuration complète et cohérente.
Dans le cadre de la méthodologie PROPULSE que nous appliquons chez Propuls’Lead, les headers de sécurité font partie du checklist de mise en ligne au même titre que la sauvegarde et le pare-feu. Le déploiement initial prend quinze minutes et la note A+ est validée avant la mise en production. Un test mensuel automatisé via l’API de securityheaders.com surveille toute régression : un plugin qui injecterait son propre header CSP ou un changement de configuration serveur qui supprimerait nos directives génère une alerte immédiate.
Sur les sites e-commerce que nous accompagnons, cette discipline a évité plusieurs incidents : une tentative de clickjacking sur une page de checkout, bloquée par X-Frame-Options DENY ; un plugin compromis qui tentait d’injecter un script de minage cryptographique, bloqué par CSP qui n’autorisait pas le domaine du script malveillant. Notre article sur Wordfence vs Sucuri, quel plugin de sécurité WordPress choisir pour une PME revient sur la couche pare-feu qui se combine avec les headers HTTP pour former une défense en profondeur.
Ce qu’il faut retenir pour configurer les headers de sécurité HTTP
Les headers de sécurité HTTP sont une couche de protection rapide à déployer et redoutablement efficace. Six points clés à retenir : Content-Security-Policy bloque les scripts injectés en listant explicitement les sources autorisées, HSTS force HTTPS pour toutes les visites futures et bloque les attaques de downgrade, X-Frame-Options DENY empêche le clickjacking en interdisant l’affichage en iframe, X-Content-Type-Options nosniff ferme une classe d’attaques par injection déguisée, l’implémentation via .htaccess prend quinze minutes et survit aux mises à jour WordPress, le test mensuel via securityheaders.com détecte toute régression. Chez Propuls’Lead, l’activation systématique de ces six headers est devenue un standard de mise en production qui ferme des attaques entières pour un effort de configuration minime.