Quand on parle de sécuriser un site WordPress, on pense vite aux mots de passe, aux mises à jour, et aux plugins. Tout cela compte. Mais il y a un autre levier, plus discret et souvent sous-estimé, qui peut réduire fortement la surface d’attaque sans toucher au code métier: les en-têtes HTTP de sécurité. Ces directives indiquent au navigateur comment traiter votre contenu, et elles rendent plusieurs classes d’attaques plus difficiles. En pratique, c’est comme installer des garde-fous autour de votre installation WordPress, au lieu de réécrire tout le véhicule.
Les en-têtes ne remplacent pas un durcissement côté serveur. Ils ne protègent pas contre tout, notamment les attaques qui passent par des failles applicatives, des mots de passe compromis ou une mauvaise gestion des rôles. En revanche, ils peuvent limiter les dégâts d’une exploitation réussie et empêcher des comportements dangereux côté navigateur.
Pourquoi les en-têtes valent le coup sur WordPress
WordPress charge beaucoup de ressources: scripts, styles, iframes (parfois via des vidéos ou des widgets), polices, images, et souvent du contenu embarqué depuis d’autres domaines. Cette richesse, c’est ce qui rend la plateforme flexible, mais c’est aussi ce qui rend le navigateur “à l’intérieur duquel votre site tourne” plus exposé.
Les en-têtes jouent alors un rôle très concret:
- Ils réduisent les risques liés à l’exécution de scripts inattendus. Ils limitent les possibilités d’intégration dans des iframes (clickjacking). Ils clarifient les types de contenu (moins de confusion MIME). Ils imposent une politique sur les références (referrer). Ils encadrent des fonctionnalités navigateur (caméra, micro, géolocalisation, etc.).
Sur un site WordPress, vous n’êtes pas en train de décider d’un seul flux. Vous composez des pages avec des thèmes, des plugins, et parfois des services tiers. Les en-têtes aident à uniformiser le comportement attendu.
Je me suis déjà retrouvé sur un site e-commerce sous WooCommerce où un simple ajustement d’en-têtes avait cassé un module d’affichage vidéo en iframe, rien d’exotique, mais suffisamment gênant pour faire perdre une demi-journée. Le gain net était positif, mais ça m’a appris une règle: déployer les politiques en mode progressif et tester, surtout si vous utilisez des contenus embarqués ou des outils tiers.
Les en-têtes les plus utiles, et ce qu’ils changent réellement
Il n’existe pas “la” liste universelle parfaite. La bonne stratégie consiste à couvrir les classes d’attaques fréquentes, puis à ajuster selon vos besoins (CSP surtout). Voici les directives qui reviennent le plus souvent dans des déploiements WordPress sérieux.
Strict-Transport-Security (HSTS)
HSTS dit au navigateur: “pense en HTTPS, oublie HTTP.” Une fois qu’un site a envoyé cette directive avec une durée adaptée, le navigateur n’essaie plus la version non chiffrée, ce qui réduit fortement les risques de downgrade.
Le point délicat: si vous n’avez pas un HTTPS fiable depuis le début (certificat correct, redirections constantes), HSTS peut vous piéger. En général, on commence avec une valeur “prudente”, puis on augmente.
Content-Security-Policy (CSP)
CSP est souvent la plus puissante, et aussi la plus exigeante. Elle définit des règles de chargement de ressources, et elle peut bloquer l’exécution de scripts inline ou de scripts provenant de sources non prévues.
Sur WordPress, CSP se heurte à une réalité: thèmes et plugins ne chargent pas tous leurs scripts de la même façon, certains utilisent des inline scripts, d’autres ajoutent des balises dynamiquement. On peut toutefois avancer par étapes: d’abord passer en mode “report only” ou limiter à quelques directives, puis renforcer.
Si vous utilisez des services tiers (tracking, chat, cartes, vidéos), CSP doit les autoriser explicitement, sinon certaines fonctionnalités deviennent muettes ou cassent l’interface.
X-Frame-Options
Cette directive limite l’intégration de votre site dans des iframes. Le but est de contrer le clickjacking, quand un site malveillant charge le vôtre sous une couche visuelle trompeuse.
Aujourd’hui, on voit aussi frame-ancestors dans CSP. Les deux approches sont liées. L’idée reste la même: empêcher l’intégration non désirée.
X-Content-Type-Options
Avec nosniff, vous indiquez au navigateur de ne pas “deviner” le type de contenu. Cela réduit les risques liés à la confusion MIME, notamment sur des endpoints qui serviraient involontairement un contenu inattendu.
Referrer-Policy
Cette directive contrôle ce que le navigateur envoie comme en-tête Referer vers les sites tiers. En réduisant les fuites de données (URL complètes, paramètres sensibles), vous gagnez en confidentialité et vous limitez les informations qui pourraient être exploitées en cas d’analytics ou de tracking agressifs.
Permissions-Policy
Elle encadre des fonctionnalités du navigateur, par exemple la géolocalisation, la caméra ou le micro. Sur un site vitrine WordPress, le plus simple est souvent de désactiver ce qui n’est pas nécessaire.
X-XSS-Protection
On le voit encore dans certains guides. Dans beaucoup de navigateurs modernes, ce mécanisme a moins d’impact qu’avant. Je le traite comme secondaire, pas comme le pilier de la défense. CSP reste la référence pratique.
Une politique “propre” sans se tirer une balle dans le pied
L’erreur fréquente, c’est de viser le maximum immédiat. Sur WordPress, ça finit par un mélange de choses cassées: menus qui ne s’affichent plus, formulaires qui cessent de fonctionner, tracking qui ne remonte plus rien, ou contenu embarqué qui ne charge pas.
À l’inverse, rester à zéro est une occasion manquée. La meilleure approche que j’ai vue fonctionner dans le temps consiste à raisonner par étapes et par priorités.
- D’abord, sécuriser ce qui est très rarement incompatible: nosniff, une politique de referrer raisonnable, et HSTS une fois que HTTPS est béton. Ensuite, gérer le “risque de rupture”: X-Frame-Options et Permissions-Policy. Enfin, arriver sur CSP, en commençant par des directives qui bloquent peu, puis en renforçant en observant les effets.
CSP est le domaine où votre contexte WordPress compte le plus. Une politique “forte” sur un site de blog peut devenir injouable sur un site utilisant un énorme écosystème de scripts tiers. Le bon niveau dépend de vos pages, de vos plugins, et de la façon dont votre thème charge ses assets.
Où configurer ces en-têtes sur WordPress
Vous avez essentiellement trois voies: côté serveur (nginx ou Apache), via un mécanisme de reverse proxy ou CDN, ou via un plugin WordPress. Chacune a ses avantages, et toutes ont des pièges.
Côté serveur (nginx ou Apache): le meilleur contrôle
Configurer les en-têtes au plus près du serveur qui sert vos pages vous donne une cohérence solide. Vous évitez les surprises liées à des caches WordPress, ou à des pages qui ne passent pas par le même chemin.
Sur un serveur nginx, on utilise généralement add_header dans des blocs adaptés. Sur Apache, c’est souvent Header set ou Header always set. Les détails exacts varient selon votre configuration, notamment pour s’assurer que l’en-tête est envoyé même pour des redirections ou des réponses spécifiques.
Le piège classique ici: oublier les règles sur les sous-chemins, ou envoyer les en-têtes sans “always” sur certaines réponses, ce qui crée une politique incohérente selon que vous êtes sur une page, une image, ou un endpoint.
Via un CDN ou un reverse proxy
Si vous passez par Cloudflare, Fastly, ou un service équivalent, vous pouvez injecter des en-têtes en amont. C’est pratique, surtout si vous ne touchez pas à votre serveur.
Le compromis: CSP et d’autres politiques doivent parfois être ajustées selon que les assets sont servis depuis le CDN, et certains headers pourraient interagir avec ceux ajoutés par WordPress. Résultat: des conflits, ou des directives dupliquées, parfois avec des effets difficiles à diagnostiquer.
Via un plugin WordPress
Beaucoup de plugins ajoutent des en-têtes. C’est confortable, surtout pour démarrer. Mais je recommande de vérifier la qualité de l’implémentation: est-ce que le plugin applique bien les règles à toutes les pages? Est-ce qu’il gère correctement les options “report only” pour CSP? Est-ce qu’il laisse la main sur les directives spécifiques à certains endpoints?
Sur des sites avec cache agressif, certains plugins d’en-têtes peuvent aussi interagir avec la mise en cache, et vous vous retrouvez avec des en-têtes qui ne correspondent pas au dernier réglage le temps d’un flush.
Je ne dis pas que les plugins sont mauvais. Je dis que sur la durée, je préfère une configuration serveur ou reverse proxy, parce qu’elle est plus stable et moins dépendante de l’état WordPress.
Construire CSP sans perdre le contrôle
CSP est la partie qui demande le plus de méthode. Une politique trop permissive ne sert à rien, une politique trop stricte casse vite des pages. L’équilibre se trouve souvent en travaillant en deux phases.
D’abord, observer. Ensuite, renforcer.
Concrètement, vous pouvez commencer par une CSP en mode “report only”, ce qui envoie des événements de violation sans bloquer l’affichage. Vous repérez ainsi quelles ressources sont chargées, et quelles directives déclenchent des alertes.
Ensuite, vous activez le blocage progressif. Par exemple, vous commencez par autoriser les styles et scripts nécessaires, puis vous rendez les règles plus strictes, comme l’interdiction des scripts inline si votre stack le permet.
Un exemple de stratégie, typique sur WordPress:
- Autoriser le chargement de scripts depuis votre domaine et depuis les domaines de vos plugins tiers nécessaires. Éviter d’autoriser “trop large”, car un CSP trop ouvert revient à peu près à ne rien faire. Réduire l’usage de scripts inline quand vous en avez la maîtrise. Certains thèmes s’appuient fortement dessus, alors vous pouvez être obligé de conserver une capacité inline pendant un temps, puis de migrer.
Edge case fréquent: un plugin de galerie ou un constructeur de page injecte du JS inline pour configurer un composant. Si vous bloquez immédiatement les inline scripts, vous aurez un front partiellement “mort” sans message clair pour l’utilisateur. D’où l’approche progressive.
Paramétrer la configuration, sans entrer dans une usine à gaz
Au-delà de CSP, quelques directives sont souvent plus simples à intégrer.
- Pour X-Frame-Options, le choix dépend de votre besoin. Sur un site WordPress standard, vous bloquez généralement l’embedding partout. Si vous avez un cas légitime d’intégration (rare, mais possible), vous autorisez seulement les domaines concernés. Pour Referrer-Policy, une valeur “prudente” limite l’exposition des paramètres d’URL. Pour Permissions-Policy, vous pouvez désactiver plusieurs fonctionnalités que votre site n’utilise pas, sans impacter la plupart des pages.
Ce qui compte, c’est la cohérence. Si vous envoyez une politique, assurez-vous qu’elle s’applique à ce qui est important: le HTML des pages, les redirections, et les endpoints critiques.
Une mini feuille de route pour démarrer proprement
Voici une liste courte de directives que je conseille de considérer en priorité pour un site WordPress, avec une logique de compatibilité raisonnable.
- Strict-Transport-Security (HSTS), une fois HTTPS stable Content-Security-Policy (au départ en “report only”, puis durcissement) X-Frame-Options ou frame-ancestors via CSP X-Content-Type-Options: nosniff Referrer-Policy et Permissions-Policy (selon vos usages)
Je la présente volontairement comme point de départ, pas comme contrat. Si vous utilisez des iframes légitimes (vidéos, widgets d’autres services), vous devrez adapter.
Tester et valider, parce que WordPress ne vous prévient pas
Un bon déploiement ne se juge pas à la configuration. Il se juge au comportement réel dans le navigateur. Et aussi sur les pages qui “sortent du chemin”, comme les pages de connexion, certaines pages générées par un plugin, ou les URL derrière des redirections.
Dans ma pratique, je vérifie au moins ces éléments:
- Les en-têtes sont bien présents sur les pages clés (home, article, pages d’administration, login si applicable) CSP est effectivement appliquée, pas seulement déclarée Les ressources chargées (scripts, styles, images) ne déclenchent pas un barrage de violations Les fonctionnalités d’intégration (vidéos, formulaires tiers) ne sont pas cassées Les erreurs n’ont pas été introduites via cache, notamment si vous utilisez un plugin de cache ou un CDN
Pour CSP, je fais aussi attention aux erreurs silencieuses: un composant peut rester affiché mais ne pas fonctionner. Un bouton de “newsletter” qui ne s’envoie plus, un analytics qui ne remonte plus, ou un widget de traduction qui refuse des scripts, ce sont des symptômes typiques d’une politique CSP trop stricte.
Les pièges courants, ceux qu’on rencontre vraiment
1) Du contenu externe non anticipé
Beaucoup de sites WordPress ajoutent des scripts via des plugins: chat, reCAPTCHA, cartes, vidéos, publicités, widgets de réseaux sociaux. Chaque ajout devient une source potentielle de violation CSP.
Le remède: lister vos plugins et leurs dépendances, puis ajuster CSP plutôt que de “générer une CSP parfaite” sans contexte. Dans certains cas, une micro exception ciblée sur un domaine tiers suffit, plutôt que d’ouvrir large.
2) Confusion entre en-têtes ajoutés à plusieurs endroits
Si vous configurez des en-têtes au serveur et aussi dans un plugin ou un CDN, vous pouvez vous retrouver avec plusieurs versions de CSP. Selon le navigateur, les règles peuvent se combiner ou provoquer un comportement inattendu.
Résultat: vous perdez la visibilité et vous passez en mode chasse au bug. Le conseil: n’ajoutez pas CSP à deux endroits. Décidez d’un seul endroit pour chaque directive, et documentez où.
3) HSTS trop agressif
Si votre HTTPS n’est pas stable (certificats intermittents, redirections incohérentes, ou absence temporaire de TLS), activer HSTS avec une longue durée est risqué. Commencez avec une période prudente, vérifiez les redirections, puis montez.
4) Politiques de frame qui cassent des intégrations
Si vous utilisez des iframes pour des contenus légitimes, un blocage trop strict peut couper une fonctionnalité. Ici, l’approche est de viser le meilleur compromis, soit en utilisant CSP avec frame-ancestors de façon précise, soit en réglant X-Frame-Options selon vos besoins réels.
Ce que vous gagnez concrètement (et ce que vous ne gagnez pas)
Les en-têtes de sécurité améliorent la posture, mais ils ne transforment pas un WordPress vulnérable en forteresse. Ils ne corrigent pas une faille dans un plugin. Ils ne patchent pas une escalade de privilèges. Ils ne remplacent pas une stratégie de sauvegardes et de mises à jour.
En revanche, ils réduisent la probabilité que certaines choses s’exécutent comme prévu après une injection. CSP aide à bloquer l’exécution de scripts non autorisés. Le https://gardewp.fr/securite-wordpress/ contrôle de frame limite une partie des attaques de manipulation utilisateur. nosniff empêche le navigateur d’interpréter un contenu autrement que prévu.
Autrement dit: vous ne supprimez pas le risque, vous diminuez l’impact.
Aller plus loin, sans transformer votre WordPress en projet permanent
Une fois les en-têtes en place, la tentation est de continuer à renforcer chaque semaine, jusqu’à casser quelque chose. Le bon rythme est différent selon votre stack.
Si votre site WordPress change peu, vous pouvez durcir CSP plus régulièrement. Si vous installez des plugins souvent, ou si vous faites des refontes de thème, vous devez accepter que CSP demandera parfois des ajustements.
Le meilleur réflexe consiste à garder une base documentée: quelles directives sont actives, où elles sont configurées, et quelles exceptions existent pour quels plugins. Quand un nouveau plugin arrive, vous pensez tout de suite au test CSP, plutôt que d’attaquer “au symptôme” une fois que le front commence à bugger.
Si vous voulez un point de départ pragmatique pour sécuriser site WordPress, commencez par les en-têtes simples et mettez CSP en “report only”. Le temps que vous passez à observer les violations est souvent moins coûteux que le temps passé à corriger une page cassée en production.
En pratique: choisir le bon niveau d’ambition
Une politique de sécurité n’est pas un slogan, c’est une décision d’architecture. Sur WordPress, j’ai vu des équipes viser trop fort trop vite, puis revenir en arrière. J’ai aussi vu des équipes démarrer avec un minimum viable, puis durcir au fil des itérations, jusqu’à obtenir un CSP robuste, réaliste, et stable.
Votre contexte dicte le rythme:
- site vitrine simple avec peu de scripts tiers: CSP peut être renforcée assez rapidement site avec nombreux plugins et intégrations: progression plus lente, exceptions ciblées site e-commerce ou plateforme: attention aux pages sensibles, tests plus stricts
Le bon objectif n’est pas d’atteindre un score maximal d’un outil, mais d’obtenir une politique qui tient dans le temps, sans rendre l’application fragile.
Si vous préparez un déploiement, faites-le en phases, testez sur plusieurs navigateurs, et gardez un œil sur les erreurs côté console. C’est là que les en-têtes cessent d’être une “théorie”, et deviennent un filet de sécurité utile au quotidien.