Dernière mise à jour : septembre 2026
Un site WordPress avec un certificat SSL valide et un cadenas vert dans la barre d’adresse donne une impression de sécurité. Mais HTTPS ne protège que le transport des données — le chiffrement de la connexion entre le navigateur et le serveur. Il ne dit rien sur ce que le navigateur a le droit de faire une fois la page chargée.
Sans headers de sécurité HTTP, un site reste exposé à des attaques que le HTTPS seul ne bloque pas : injection de scripts tiers (XSS), chargement du site dans un cadre invisible (clickjacking), exécution de fichiers sous un type MIME falsifié. Ces vulnérabilités ne sont pas théoriques — elles sont exploitées quotidiennement sur des sites WordPress en production dont les headers ne sont pas configurés.
Ce que sont les headers de sécurité HTTP
Les headers HTTP sont des directives envoyées par le serveur web au navigateur du visiteur avec chaque réponse. Certains de ces headers sont fonctionnels (type de contenu, cache, encodage), d’autres sont des directives de sécurité qui limitent ce que le navigateur est autorisé à faire sur la page.
Par défaut, un navigateur est permissif : il charge les scripts externes, accepte d’afficher la page dans un iframe, exécute le contenu sans vérifier son type réel. Les headers de sécurité restreignent ce comportement en définissant des règles explicites. C’est le serveur qui décide — pas le navigateur, pas WordPress, pas un plugin.
Sur une installation WordPress standard, ces headers sont absents. Le serveur renvoie la page avec les headers fonctionnels, mais aucune directive de sécurité. C’est la configuration par défaut de la plupart des hébergeurs — et c’est insuffisant pour un site en production.
Les headers essentiels et ce qu’ils protègent
Content-Security-Policy (CSP)
Le header le plus puissant — et le plus complexe à configurer correctement. CSP définit les sources de contenu autorisées pour chaque type de ressource : scripts, styles, images, polices, iframes. Si un script malveillant est injecté dans une page (via un plugin compromis, une faille XSS dans un formulaire, ou une injection en base de données), le navigateur refuse de l’exécuter s’il ne provient pas d’une source autorisée par la politique CSP.
Exemple de directive : Content-Security-Policy: default-src 'self'; script-src 'self' cdn.exemple.fr; img-src 'self' data:;
Le piège courant : une CSP trop restrictive casse le site. Les builders WordPress (Elementor, Divi) et certains plugins injectent du JavaScript et du CSS inline, qui seront bloqués par une CSP stricte. La bonne approche est de commencer en mode rapport (Content-Security-Policy-Report-Only) pour identifier les violations avant de passer en mode blocage.
X-Frame-Options
Ce header empêche le site d’être chargé dans un iframe sur un autre domaine. Sans lui, un attaquant peut intégrer le site dans une page piège, superposer des éléments invisibles, et inciter le visiteur à cliquer sur des boutons qu’il ne voit pas — c’est le clickjacking.
Directive recommandée : X-Frame-Options: SAMEORIGIN
Cela autorise l’affichage en iframe uniquement depuis le même domaine (utile pour les previews dans le tableau de bord WordPress) tout en bloquant l’intégration par des sites tiers.
X-Content-Type-Options
Sans ce header, un navigateur peut « deviner » le type MIME d’un fichier en analysant son contenu plutôt qu’en se fiant au type déclaré par le serveur. Un fichier uploadé avec une extension .jpg mais contenant du JavaScript pourrait être interprété comme un script et exécuté. C’est le MIME sniffing.
Directive : X-Content-Type-Options: nosniff
Simple, sans effet de bord, aucune raison de ne pas l’activer sur tout site en production.
Referrer-Policy
Ce header contrôle quelles informations de provenance sont transmises quand un visiteur clique sur un lien sortant depuis le site. Par défaut, l’URL complète de la page source (y compris les paramètres de requête, qui peuvent contenir des tokens, des identifiants de session ou des données sensibles) est envoyée au site de destination.
Directive recommandée : Referrer-Policy: strict-origin-when-cross-origin
Le domaine d’origine est transmis (utile pour les analytics et le SEO), mais pas le chemin complet ni les paramètres — un compromis entre confidentialité et fonctionnalité.
Permissions-Policy
Anciennement Feature-Policy, ce header contrôle l’accès aux API du navigateur : caméra, microphone, géolocalisation, paiement, plein écran. Sur un site WordPress vitrine ou e-commerce, aucune de ces fonctionnalités n’est nécessaire — mais si un script tiers injecté tente d’y accéder, le navigateur le bloquera grâce à ce header.
Exemple : Permissions-Policy: camera=(), microphone=(), geolocation=()
Les parenthèses vides signifient que la fonctionnalité est interdite pour toutes les origines, y compris le site lui-même.
Strict-Transport-Security (HSTS)
HSTS indique au navigateur de ne jamais accéder au site en HTTP — même si l’utilisateur tape l’URL sans « https:// » ou clique sur un lien HTTP. Le navigateur convertit automatiquement la requête en HTTPS avant de l’envoyer. Sans HSTS, la première requête HTTP crée une fenêtre de vulnérabilité exploitable par une attaque man-in-the-middle.
Directive recommandée : Strict-Transport-Security: max-age=31536000; includeSubDomains
Le max-age définit la durée (en secondes) pendant laquelle le navigateur se souvient de la politique — ici un an. includeSubDomains applique la règle aux sous-domaines.
HSTS : les points d’attention
HSTS est le header le plus efficace contre les attaques de type man-in-the-middle, mais aussi celui qui peut causer le plus de dégâts s’il est mal configuré.
Le risque d’un déploiement précipité
Une fois qu’un navigateur a reçu un header HSTS avec un max-age d’un an, il refuse catégoriquement de charger le site en HTTP pendant toute cette durée. Si le certificat SSL expire, si une migration nécessite un passage temporaire en HTTP, ou si un sous-domaine n’a pas de certificat valide alors que includeSubDomains est actif — le site devient inaccessible. Et ce n’est pas un problème côté serveur : c’est le navigateur du visiteur qui bloque, et il n’y a rien à faire côté serveur pour annuler la directive avant l’expiration du max-age.
La bonne pratique : commencer avec un max-age court (300 secondes = 5 minutes) pour vérifier que tout fonctionne, puis augmenter progressivement vers la valeur cible.
La preload list
Google maintient une liste HSTS preload partagée par tous les navigateurs majeurs. Un domaine inscrit sur cette liste sera toujours chargé en HTTPS, même lors de la toute première visite — avant que le navigateur n’ait reçu le header HSTS du serveur. C’est le niveau de protection maximal.
Pour être éligible, le site doit servir un header HSTS valide avec max-age d’au moins un an, includeSubDomains et la directive preload. L’inscription est volontaire — mais la désinscription prend des mois. Il faut être certain que tous les sous-domaines supportent HTTPS avant de soumettre le domaine.
Implémentation : serveur vs plugin WordPress
Il y a deux façons de configurer les headers de sécurité sur un site WordPress. Elles ne se valent pas.
Configuration au niveau serveur
C’est l’approche correcte. Les headers sont ajoutés par le serveur web lui-même — OpenLiteSpeed, Nginx, Apache — avant que PHP et WordPress ne soient même sollicités. La configuration se fait dans les fichiers du serveur (vhost, .htaccess, ou panneau de gestion comme ServerAvatar).
Avantages : les headers sont envoyés sur toutes les réponses (y compris les fichiers statiques — images, CSS, JS — que WordPress ne gère pas), aucune dépendance à un plugin, aucun impact sur les performances PHP, et la configuration persiste quelle que soit l’état de WordPress.
C’est ce que SL SYSTEM configure sur les serveurs managés : les headers de sécurité font partie de la configuration de sécurité du serveur, pas de l’application WordPress.
Configuration par plugin WordPress
Des plugins comme Headers Security Advanced ou HSTS WP ajoutent les headers via PHP, en utilisant la fonction header() de WordPress. C’est une solution de repli pour les propriétaires de sites qui n’ont pas accès à la configuration serveur — typiquement sur un hébergement mutualisé.
Limites : les headers ne sont envoyés que sur les réponses traitées par PHP/WordPress. Les fichiers statiques (images, polices, scripts) servis directement par le serveur web ne portent pas ces headers. Et si WordPress plante (erreur fatale, base de données inaccessible), les headers de sécurité disparaissent avec lui — précisément au moment où le site est le plus vulnérable.
Un plugin vaut mieux qu’aucun header. Mais pour un site en production géré professionnellement, la configuration serveur est la norme.
Comment vérifier ses headers
Deux méthodes, complémentaires :
- securityheaders.com — Analyse les headers renvoyés par le serveur et attribue une note de F à A+. Un site sans aucun header de sécurité obtient un F. La note A+ exige tous les headers essentiels correctement configurés, y compris CSP. C’est un bon outil de diagnostic rapide, mais la note ne dit pas si les directives sont adaptées au site — une CSP qui autorise tout (
unsafe-inline,unsafe-eval) obtient un meilleur score qu’aucune CSP, mais ne protège pas grand-chose. - DevTools du navigateur — Dans Chrome ou Firefox, onglet Network, cliquer sur la requête principale du document, puis lire les Response Headers. C’est la vérification la plus fiable : ce sont les headers réels que le navigateur reçoit, pas un test externe qui peut être affecté par un CDN ou un proxy intermédiaire.
Un audit de sécurité des headers devrait faire partie de la maintenance continue d’un site — les headers peuvent disparaître après une mise à jour serveur, un changement de configuration, ou une migration.
FAQ
Les headers de sécurité ont-ils un impact sur les performances du site ?
Non. Les headers de sécurité sont des métadonnées textuelles ajoutées à la réponse HTTP — quelques octets supplémentaires par requête. Ils n’ajoutent aucun traitement côté serveur (quand ils sont configurés au niveau serveur web) et n’impactent pas le temps de chargement. CSP peut même améliorer les performances perçues en bloquant le chargement de scripts tiers non autorisés.
Un plugin de sécurité WordPress (Wordfence, Sucuri) configure-t-il automatiquement les headers ?
Non. Les plugins de sécurité WordPress se concentrent sur le pare-feu applicatif, le scan de malware et la protection contre le brute force. La configuration des headers HTTP n’entre pas dans leur périmètre — ce sont deux couches de sécurité complémentaires mais distinctes. Wordfence protège WordPress ; les headers protègent le navigateur du visiteur.
Mon hébergeur dit que le site est « sécurisé » — les headers sont-ils déjà en place ?
Dans la majorité des cas, non. « Sécurisé » chez un hébergeur signifie généralement que le certificat SSL est actif et que le pare-feu réseau fonctionne. Les headers de sécurité HTTP sont rarement configurés par défaut sur les hébergements mutualisés ou les VPS standard. La vérification prend 10 secondes sur securityheaders.com — si le résultat est un F ou un D, les headers ne sont pas en place.
Vous voulez savoir si vos headers de sécurité sont correctement configurés ?