Quand on parle de “sécuriser WordPress”, on pense d’abord aux identifiants, aux plugins et à la mise à jour. C’est normal, mais il y a une autre ligne de défense, souvent sous-estimée, qui s’exprime dans les en-têtes HTTP. Ceux-ci ne remplacent pas un pare-feu ni une hygiène logicielle solide, mais ils réduisent la surface d’attaque et limitent les comportements dangereux côté navigateur.
Parmi eux, HSTS (HTTP Strict Transport Security) tient un rôle particulier. Il ne “bloque” pas directement une attaque comme le ferait un WAF, mais il empêche les navigateurs de retomber sur des connexions non chiffrées. En pratique, c’est une protection contre des scénarios assez concrets, notamment les tentatives de downgrade en HTTP et, plus largement, les angles morts quand des redirections ou des liens externes reviennent en arrière.
Dans ce qui suit, je passe en revue HSTS et d’autres en-têtes utiles, avec des exemples concrets, des pièges fréquents, et des choix réalistes selon votre configuration.
Pourquoi les en-têtes comptent vraiment
Un site WordPress moderne mélange souvent du rendu serveur, des ressources statiques, des scripts tiers, et parfois des formulaires embarqués. Les navigateurs font de plus en plus de contrôles, et la sécurité évolue dans ce sens. Les en-têtes servent justement à “commander” ces contrôles.
Ils jouent sur plusieurs axes :
- forcer l’usage du HTTPS et limiter les erreurs de transport (HSTS), réduire les risques liés à l’exécution de scripts injectés (CSP, X-Content-Type-Options, etc.), empêcher l’application de comportements de navigateur non désirés (X-Frame-Options, Permissions-Policy), améliorer les garde-fous contre le chargement de contenus dangereux ou inattendus.
Le point clé est que les en-têtes ne dépendent pas uniquement de WordPress. Ils se configurent au niveau du reverse proxy, du serveur web (Nginx, Apache), d’un CDN, ou d’un service applicatif. Donc, selon votre architecture, vous avez parfois un levier plus rapide qu’en modifiant le cœur WordPress.
HSTS : le verrou côté navigateur
HSTS indique au navigateur que le domaine doit uniquement être accessible en HTTPS pendant une durée donnée. Concrètement, après une première visite en HTTPS, le navigateur garde en mémoire la consigne et évite d’utiliser HTTP dans la suite.
La valeur de l’en-tête ressemble à ceci :
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Les paramètres méritent une lecture prudente :
- max-age définit la durée de la règle. Un an correspond à 31536000 secondes. Plus c’est long, plus il faut être sûr de votre HTTPS. includeSubDomains étend la règle à tous les sous-domaines. preload signale que vous souhaitez entrer dans la liste de préchargement côté navigateurs, ce qui implique de répondre à des critères stricts.
Le piège classique : se tromper de domaine au mauvais moment
HSTS devient dangereux si vous activez la règle avant que tout soit parfaitement stable en HTTPS. Le cas typique, c’est un sous-domaine oublié (par exemple mail.example.com ou admin.example.com), ou un CDN qui n’est pas encore en place.
Si vous activez includeSubDomains trop tôt, et qu’un sous-domaine ne répond pas correctement en HTTPS, les navigateurs des visiteurs vont refuser HTTP ensuite, ce qui peut casser des pages qui fonctionnaient encore quelques heures avant.
L’erreur inverse existe aussi. Si vous mettez un max-age trop court, vous n’obtenez pas l’effet recherché, et l’intérêt réel de HSTS baisse.
Une approche pragmatique avant d’aller loin
Dans la pratique, je recommande d’abord d’installer une base saine : HTTPS fonctionnel partout, redirections propres, certificats OK sur les sous-domaines. Ensuite seulement, vous pouvez passer de max-age modéré à plus long.
Je ne donne pas un “chiffre magique” car tout dépend de votre mobilité (noms de domaine, sous-domaines, changements d’hébergement). Mais l’idée est la même : réduire le risque au moment où vous ajoutez l’en-tête.
HSTS et chargements “externes” ou environnements de test
Si vous avez des environnements de staging, ou des clients qui testent en interne, la règle HSTS peut compliquer les cycles de bascule. Un navigateur peut conserver une politique plusieurs mois si max-age est élevé. Cela ne veut pas dire qu’il faut éviter HSTS, mais il faut le planifier.
Sur des environnements de préprod, je privilégie souvent des réglages temporaires au niveau de l’infrastructure (et pas seulement “un plugin” WordPress). C’est plus facile à gérer et moins risqué.
X-Frame-Options : réduire le risque de clickjacking
Le clickjacking consiste à charger votre page dans un iframe sur un site tiers, puis à tromper l’utilisateur pour qu’il clique sur des éléments de votre interface. Historiquement, X-Frame-Options a été utilisé pour bloquer ou encadrer ce comportement.
Valeurs courantes :
- DENY : aucun iframe autorisé, SAMEORIGIN : seulement si la page est encadrée par le même site, des configurations basées sur des méthodes plus modernes existent aussi, mais elles varient selon les plateformes.
Sur un site WordPress classique, DENY est souvent acceptable. En revanche, si vous utilisez des outils d’intégration qui nécessitent réellement un iframe (widgets, certains portails, embeds spécifiques), vous devrez être plus fin.
Le point de vigilance
Si votre site doit être embarqué sur un domaine contrôlé, SAMEORIGIN ne suffira pas toujours. Dans ces cas, on traite le besoin au niveau CSP (cadre de chargement, directives liées aux frames) ou via un paramétrage précis, plutôt que de tout bloquer sans réflexion.
X-Content-Type-Options : éviter les surprises de type MIME
Cette directive demande au navigateur d’honorer les types déclarés par le serveur. En particulier, elle aide à éviter des cas où un fichier est traité autrement que prévu.
L’en-tête :
X-Content-Type-Options: nosniff
Sur WordPress, ça limite des classes d’erreurs de configuration. Ce n’est pas la mesure la plus spectaculaire, mais elle est généralement “peu risquée” si votre serveur renvoie correctement les bons Content-Type.
Quand ça peut poser problème
Si une configuration serveur renvoie des types inattendus pour certaines routes, un durcissement peut révéler le bug. C’est plutôt une bonne nouvelle: vous corrigez la racine au lieu de laisser le navigateur “inventer”.
Referrer-Policy : maîtriser ce qui fuit
Les navigateurs envoient parfois un référent (source) dans les requêtes sortantes. Referrer-Policy permet de contrôler ce comportement.
Vous pouvez viser des politiques du type :
- n’envoyer pas de référent, envoyer seulement une partie, ou limiter selon l’origine.
Le bon choix dépend de vos besoins analytics, de la sécurité et de la conformité. Par exemple, pour réduire la fuite d’informations sur des pages sensibles (chemin de l’URL, paramètres), une politique restrictive est utile.
Le piège, c’est que certaines mesures marketing ou tracking s’appuient sur des référents précis. Avant de durcir, vérifiez ce que vous perdez côté instrumentation.
Permissions-Policy : éviter que des capacités soient activées trop largement
Cette directive sert à contrôler l’accès à certaines fonctionnalités du navigateur, comme la géolocalisation, le micro, la caméra, etc. L’intérêt est double : réduire la surface et donner un cadre clair à ce que votre site est autorisé à utiliser.
Sur une application qui n’utilise pas la caméra, ni le micro, ni la géolocalisation, la politique peut être très stricte.
La difficulté, c’est que les pratiques varient selon les plugins WordPress. Un formulaire d’assistance, un module “chat”, ou un outil de visioconférence peuvent demander certaines capacités. En durcissant sans inventaire, vous risquez de casser des fonctionnalités.
Ici, la meilleure approche consiste à regarder réellement ce que le site utilise, plutôt que d’appliquer un modèle “par défaut”.
CSP : la vraie force, mais aussi le vrai travail
Content Security Policy (CSP) est souvent l’en-tête le plus puissant pour contrer des attaques par injection de scripts. Elle n’empêche pas tout, mais elle rend beaucoup de scénarios beaucoup plus difficiles.
Une CSP peut contrôler :
- quelles sources de scripts sont autorisées, quelles images, styles, polices peuvent être chargées, si le navigateur autorise des scripts inline, et même si des formulaires ou requêtes peuvent être envoyés vers certaines destinations.
Exemple réaliste (et prudence)
Beaucoup d’installations WordPress ont des scripts inline pour des réglages ou des thèmes. Une CSP trop stricte peut casser le rendu.
L’approche qui marche le mieux dans la vraie vie consiste souvent à partir d’une CSP en mode “progressive”, par exemple en commençant avec report-only (si vous pouvez). On observe les violations dans les logs, puis on durcit. Cela demande du temps, mais évite le moment “tout est cassé sur prod”.
Pourquoi les plugins compliquent la CSP
Un plugin peut injecter du JavaScript, charger des assets depuis des domaines externes, ou utiliser des mécanismes qui ne rentrent pas facilement dans une CSP stricte. Souvent, on croit “avoir un site simple”, puis on découvre un CDN tiers pour les polices, un service de tags pour le tracking, et un script chat qui charge des ressources de plusieurs domaines.
Résultat : CSP devient un projet d’alignement. Pas un bouton magique.
La paire “Referrer-Policy” et “cookies” : ne confondez pas tout
Quand on parle de sécurité, on mélange facilement les en-têtes côté navigateur et les attributs côté cookie, alors que ce sont deux choses distinctes.
Les en-têtes listés ici agissent sur le comportement du navigateur et le chargement des ressources. Les cookies, eux, ont des attributs comme Secure, HttpOnly, SameSite, qui s’imposent côté serveur.
Cela dit, il y a un lien pratique : un durcissement “transport et chargement” rend souvent plus visibles les réglages cookie manquants, parce que certaines protections réduisent la fenêtre des attaques.
Si vous travaillez sur les en-têtes, profitez-en pour vérifier les cookies sensibles et leur configuration. WordPress peut vous aider, mais beaucoup dépend de votre stack (reverse proxy, plugins, règles applicatives).
HTTP headers côté infrastructure : où les configurer
Une question revient souvent : “je mets ça dans WordPress ou dans mon serveur ?”
Pour la majorité des en-têtes de sécurité, la bonne réponse est “dans l’infrastructure”, parce que :
- c’est centralisé, c’est cohérent sur toutes les routes, c’est appliqué même aux pages générées par des plugins, vous évitez d’avoir une logique de sécurité dispersée dans le PHP.
Concrètement, selon votre cas :
- Nginx ou Apache peuvent ajouter les en-têtes, un CDN peut faire de même, un reverse proxy (ou un load balancer) peut injecter les directives.
Si vous êtes sur une plateforme managée, l’interface peut offrir des options “Security headers” qui permettent de mettre en place HSTS, X-Frame-Options, CSP, etc.
Un détail qui change tout : pages en HTTP et redirections
HSTS suppose que votre domaine répond correctement en HTTPS. Il faut donc que les redirections soient fiables.
Un cas typique : une redirection mal gérée sur certaines URL, une exception pour un plugin de santé, un endpoint d’API qui répond parfois sans Strict-Transport-Security. Si vous activez HSTS global, vous limitez les scénarios où un navigateur “rattrape” des erreurs.
Mettre en place HSTS et les en-têtes sans casser le site
Je vous propose une méthode de travail basée sur des retours terrain, sans promesse “universelle”.
Vérifier d’abord la portée
Avant d’ajouter includeSubDomains, listez vos sous-domaines réellement utilisés. Un domaine principal “www” ne suffit pas. Prenez en compte :
- sous-domaines pour emails (même si ce n’est pas votre site), sous-domaines d’admin, sous-domaines de services externes intégrés, domaines utilisés pour des callbacks (paiement, webhooks).
Ensuite, validez que chacun répond en HTTPS et que le certificat couvre bien ces noms.
Introduire progressivement
Pour HSTS, un max-age modéré permet de tester l’effet. Pour CSP, la stratégie “report-only puis durcir” limite les surprises. Pour X-Frame-Options, commencez par une politique cohérente avec votre besoin d’intégration.
Voici une check-list courte que j’utilise quand je dois faire ce type de bascule :
- confirmer HTTPS sur le domaine et les sous-domaines (certificats et redirections), tester les pages clés et les parcours utilisateurs (connexion, formulaires, recherche), vérifier les endpoints qui chargent des scripts tiers (tracking, chat, consentements), observer les erreurs navigateur et les logs serveur après activation, prévoir une fenêtre de changement où vous pouvez rollback rapidement.
C’est moins “spectaculaire” qu’un grand plan, mais c’est ce qui évite les incidents de dernière minute.
Où ça se complique : cas concrets sur WordPress
WordPress a deux particularités qui rendent les en-têtes plus délicats qu’on ne l’imagine : la fragmentation plugin et l’intégration de contenus externes.
Scénario 1 : un thème ou plugin injecte des scripts inline
Si votre CSP interdit unsafe-inline, vous pouvez casser des composants. La solution passe souvent par :
- réduire les scripts inline, déplacer des scripts vers des fichiers externes, ajuster la CSP en identifiant les “non négociables”.
Si vous avez une CSP très stricte “du premier coup”, vous allez perdre du temps en débogage. J’ai déjà vu des sites rester inopérants pendant des heures à cause d’une seule directive trop agressive sur des événements inline.
Scénario 2 : des intégrations externes demandent des cadres, ou des sources
Des services vidéo, des widgets, des lecteurs de formulaires peuvent utiliser des iframes. X-Frame-Options: DENY rend ces intégrations impossibles. L’option la plus saine consiste à évaluer ce qui doit être autorisé, puis à ajuster CSP sur les domaines de confiance.
Ici, la “sécurité maximale” n’est pas un https://gardewp.fr/securite-wordpress/ objectif absolu. Elle doit être compatible avec l’usage réel du site.
Scénario 3 : HSTS et test de migration
Lors d’une migration de DNS ou d’un changement d’hébergement, il arrive que pendant quelques minutes l’endpoint HTTPS réponde de façon inattendue. Si HSTS est activé avec un max-age élevé et includeSubDomains, une partie des visiteurs peut être pénalisée.
Le bon réflexe est de faire les changements sensibles sur une période où l’observation est possible, et d’éviter les opérations “risquées” juste après activation de HSTS ou de CSP.
Exemple d’ensemble d’en-têtes “raisonnable” (sans prétendre à l’universalité)
Plutôt que de vous donner un pack à copier-coller, je préfère cadrer ce qui est généralement facile à adopter, puis indiquer ce qui exige une validation.
Voici les directives que beaucoup de sites WordPress peuvent appliquer sans trop de friction, à condition d’avoir vérifié HTTPS, intégrations et types MIME :
- Strict-Transport-Security (avec max-age adapté, et prudence avec includeSubDomains), X-Frame-Options (souvent SAMEORIGIN ou DENY selon l’usage), X-Content-Type-Options: nosniff, Referrer-Policy (selon vos besoins d’analytics et de confidentialité), une base de CSP, d’abord en “assouplie” ou en mode observation si nécessaire.
Si vous ne voulez implémenter qu’une partie au début, commencez par HSTS, X-Content-Type-Options, et X-Frame-Options, puis travaillez CSP ensuite. La logique est simple : ces en-têtes réduisent des risques sans trop dépendre de la structure exacte du contenu, contrairement à CSP qui demande un alignement plus fin.
Conseils de validation : comment contrôler que tout fonctionne
Les en-têtes ne servent à rien si personne ne les observe. Mais les vérifier uniquement par “ça semble marcher dans mon navigateur” ne suffit pas.
Je procède d’ordinaire ainsi :
- ouvrir les pages concernées et vérifier la présence des en-têtes dans l’inspecteur réseau, tester depuis plusieurs navigateurs (ils interprètent certains détails différemment), vérifier les formulaires et chargements de ressources externes (scripts, polices, iframes), contrôler les erreurs côté console JavaScript pour CSP.
Pour HSTS, le test est particulier : le comportement dépend du cache HSTS du navigateur. Vous ne verrez pas forcément l’effet immédiat si vous avez déjà visité le site. Une approche consiste à tester avec un profil navigateur “frais” ou une session nettoyée, au moins pour valider la logique.
Le vrai sujet : mesurer le risque, pas cocher des cases
On voit souvent des guides qui empilent des en-têtes sans tenir compte du site réel. Le problème n’est pas que ces en-têtes soient “mauvais”, c’est qu’ils peuvent entrer en conflit avec :
- des intégrations iframe, des scripts inline existants, des dépendances externes multi-domaines, des exigences analytics.
Un durcissement utile est celui qui survit au monde réel. Le bon équilibre, c’est d’abord traiter le transport (HSTS), puis le chargement et le cadre (nosniff, X-Frame-Options, Referrer-Policy), puis de prendre le temps sur CSP.
C’est souvent là que la protection WordPress gagne en maturité. Pas parce que WordPress devient invulnérable, mais parce que le navigateur devient moins permissif face aux mauvaises intentions et aux erreurs.
Pièges à éviter absolument
Sans faire une liste exhaustive, il y a quelques erreurs récurrentes :
- activer includeSubDomains avant d’avoir validé tous les sous-domaines, forcer une CSP trop stricte sans phase d’observation, appliquer DENY dans X-Frame-Options alors que le site dépend d’iframes, oublier que certains plugins chargent des ressources depuis des domaines inattendus, confondre ce qui relève du serveur (en-têtes) et ce qui relève de WordPress (contenu et plugins).
Ce sont des détails, mais ils décident souvent entre “protection accrue” et “panne”.
Vers une stratégie de sécurité cohérente
HSTS et les en-têtes de sécurité ne sont pas un dispositif isolé. Ils s’inscrivent dans une stratégie plus large : mises à jour WordPress et plugins, durcissement des accès, réduction des scripts tiers au strict nécessaire, audit des comptes et des rôles, et configuration de cookies quand c’est pertinent.
Si vous ne retenez qu’une idée, ce serait celle-ci : les en-têtes sont un levier puissant, mais ils demandent un minimum de cartographie de votre site, surtout sur WordPress où l’écosystème de plugins peut changer les besoins rapidement. Une fois que vous avez identifié ce qui doit être autorisé (scripts, cadres, sources), les directives deviennent un cadre stable, et non une série d’essais au hasard.
Quand la configuration est en place, vous gagnez quelque chose de précieux : la sécurité devient plus prévisible. Et cette prévisibilité, sur un site vivant, vaut autant que les en-têtes eux-mêmes.