Sur WordPress, l’attaque XSS (Cross-Site Scripting) suit souvent un scénario très humain: quelqu’un pense que “c’est juste du texte”, ou que “le champ est contrôlé par le thème”, ou encore que “le contenu vient de l’administrateur, donc c’est fiable”. Le problème, c’est que XSS ne demande pas forcément une grosse faille. Il suffit qu’une donnée non fiable arrive quelque part dans la page, puis soit interprétée par le navigateur comme du code.
J’ai vu ce type d’incident sur des sites qui n’avaient pas l’air “fragiles”: plugins bien notés, thème propre, mises à jour à jour. Et pourtant, un formulaire léger, une fonctionnalité d’affichage, ou un bloc personnalisé a laissé passer une chaîne mal échappée. Le résultat ressemble souvent à une simple altération de page, puis très vite à un vol de session, un phishing dans un coin de l’interface, ou une redirection silencieuse.
Voici comment comprendre les attaques XSS dans le contexte WordPress, et surtout comment bâtir une protection WordPress réaliste, où chaque couche réduit le risque, sans casser votre site.
Comprendre XSS, côté navigateur et côté WordPress
XSS, c’est l’exploitation du fait qu’un navigateur exécute ce qu’il croit être du code. Si une application affiche des données utilisateur sans les convertir correctement en texte, un attaquant peut injecter des morceaux de script, ou des attributs qui déclenchent un comportement.
Sur WordPress, il y a deux caractéristiques qui compliquent les choses:
1) WordPress est une plate forme d’affichage. Beaucoup de contenu passe par des thèmes, des blocs, des shortcodes, et des templates. Une seule sortie mal échappée peut suffire. 2) La “surface d’attaque” n’est pas uniquement les formulaires de connexion. Même un champ d’auteur, une URL, une métadonnée, ou un paramètre en query string peut devenir dangereux s’il est re-copié dans le HTML sans échappement adapté.
Dans la pratique, on rencontre surtout trois familles:
- XSS réfléchi: l’attaquant injecte via une URL, par exemple un paramètre ?q=..., puis la page renvoie la donnée dans un endroit du HTML. XSS stocké: l’attaquant fait persister la charge dans la base, par exemple via un champ de profil, un avis, un champ personnalisé d’article, ou un commentaire. Les visiteurs qui consultent la page reçoivent l’injection. XSS basé sur DOM: la page charge du contenu via JavaScript, puis reconstruit du HTML à partir de données qui n’ont pas été traitées correctement.
La “bonne” nouvelle, c’est que les mitigations se recoupent. La mauvaise, c’est qu’elles demandent de la discipline sur la sortie et sur l’entrée, pas seulement sur les formulaires.
Le point central: l’échappement de sortie, pas seulement la validation d’entrée
On peut faire de la validation à l’entrée, filtrer au moment de l’envoi, ou restreindre les rôles. Tout cela compte. Mais dans les projets WordPress que j’ai accompagnés, la faille la plus fréquente reste la sortie.
Autrement dit, vous pouvez parfaitement limiter la longueur d’un champ, et malgré tout tomber dans XSS si vous faites par exemple:
Echo $_GET['q'];Ou même:
Echo $custom_field;Sans échappement adapté à l’endroit où la donnée est affichée (texte HTML, attribut, URL, script, style, etc.).
WordPress fournit des fonctions d’échappement et de nettoyage qui ne sont pas décoratives. Elles ont un objectif précis: transformer une chaîne potentiellement dangereuse pour qu’elle soit rendue comme donnée, pas comme code.
Échappement en fonction du contexte
Le contexte détermine l’échappement:
- Si vous affichez du texte dans du HTML, utilisez un échappement de type “texte”. Si vous construisez une URL, vous devez échappement pour attribut et validation d’URL. Si vous placez une donnée dans un attribut HTML, l’échappement doit protéger la valeur de l’attribut.
Sur WordPress, on voit souvent des erreurs simples: utiliser esc_html() alors que la donnée est dans une URL, ou l’inverse. Les fonctions sont proches, mais pas identiques.
Exemples typiques à corriger dans votre code custom (thème enfant, plugin maison, template de bloc):
// Mauvais Echo $title; // Mauvais Echo 'lien'; // Bon, texte Echo esc_html( $title ); // Bon, URL dans href Echo 'lien';Notez aussi que esc_html() ne suffit pas à transformer une URL en URL sûre. Et esc_url() n’est pas une protection générique pour du texte.
Les endroits où XSS se cache le plus souvent dans un site WordPress
XSS ne “choisit” pas une page au hasard. Il exploite un endroit où la donnée utilisateur se transforme en HTML de manière implicite.
Voici les zones qui reviennent le plus dans les audits pratiques:
- templates de thèmes qui affichent des paramètres dans un bloc de titre ou une bannière shortcodes personnalisés qui concatènent des chaînes sans échappement champs ACF (ou similaires) rendus dans une page sans passer par le bon filtre templates de recherche ou pages “tag” où un paramètre GET est réinjecté formulaires “custom” où on affiche ensuite le message, par exemple dans une page de remerciement
Une anecdote rapide: sur un site de contenu, le code “semblait propre”. Les champs étaient saisis via l’espace d’administration, donc “pas d’attaquant”. Sauf que le champ en question était édité via un rôle utilisateur, et surtout réutilisé tel quel dans un template de recherche. Un utilisateur malveillant a injecté une charge dans un champ d’auteur, puis l’a rejouée via l’URL. Résultat: chaque recherche affichait l’injection pour certains visiteurs. La validation à l’entrée n’avait pas suivi la logique d’affichage.
L’idée clé: un attaquant cherche des chemins où une donnée non fiable peut entrer et sortir dans le même flux, sans transformation sûre.
Vérifier vos sorties: une méthode simple, presque “mécanique”
Plutôt que de “faire confiance” au contenu, adoptez une approche de vérification sur votre code custom.
Je recommande une règle de travail: pour chaque variable que vous affichez dans le HTML, demandez-vous dans quel contexte elle atterrit.
Cela peut sembler scolaire, mais c’est redoutable. Sur des plugins ou thèmes maison, on trouve vite les endroits à risque: echo direct, concaténation HTML, balises de script construites à partir d’une variable, ou création de fragments HTML côté serveur.
Si vous utilisez des blocs dynamiques (Gutenberg) ou des shortcodes, la discipline devient encore plus importante. Les éditeurs construisent des pages, mais ce n’est pas eux qui garantissent la sécurité.
Un micro-checklist de détection
Voici une liste courte de ce que j’inspecte en priorité quand je dois évaluer la surface XSS d’un code WordPress:
Les echo, print, return qui affichent une valeur provenant de $_GET, $_POST, d’un cookie, ou d’un champ d’admin. Les concaténations de balises HTML construites via une variable. Tout affichage dans un attribut, par exemple href, src, title, ou un attribut data-*. Les shortcodes et blocs qui manipulent du contenu “brut”. Les sorties JavaScript construites côté serveur, comme var x = '...';.Si vous voyez “je filtre à l’entrée”, mais pas “je protège à la sortie”, c’est souvent là que ça casse.
Nettoyer le contenu autorisé: wp_kses et la logique d’autorisation
WordPress autorise le contenu riche, notamment via l’éditeur et les rôles. Vous ne devez pas chercher à tout bloquer. La bonne approche, c’est d’autoriser ce que vous devez autoriser, puis de refuser le reste.
C’est là que des fonctions comme wp_kses_post() et les variantes entrent en jeu. L’idée n’est pas seulement “enlever des tags”, c’est aussi empêcher les attributs ou protocoles dangereux.
Mais attention à un piège courant: nettoyer un contenu et quand même l’afficher de façon non sûre. Même un contenu “nettoyé” doit être rendu avec l’échappement correspondant à l’endroit où il va. Dans un contenu riche, wp_kses_post() aide, mais si vous placez la sortie dans un attribut ou dans un script, les règles changent.
En pratique, pour du HTML, wp_kses_post() est utile si vous autorisez certains tags. Pour du texte simple, l’échappement de sortie suffit généralement, sans nécessiter un nettoyage HTML.
La protection côté navigateur: CSP pour réduire l’impact
Même avec une bonne hygiène serveur, une défense en profondeur reste utile. Une CSP (Content Security Policy) ne “répare” pas une XSS, elle limite souvent sa portée.
Une CSP bien configurée peut empêcher l’exécution de scripts injectés depuis des sources non autorisées, ou réduire le risque de chargement externe. Elle peut aussi atténuer certaines variantes de payload.
Le revers, c’est que CSP peut casser des sites qui chargent des scripts via des sources multiples, surtout si des plugins injectent des scripts inline. Avec CSP, il faut accepter un chantier de compatibilité. Pour certains sites, c’est faisable en une journée. Pour d’autres, surtout avec beaucoup de plugins, il faut y aller par étapes.
Une approche réaliste consiste à commencer par un mode “report” (si vous avez la capacité de collecter les rapports), puis durcir progressivement. Je conseille de tester sur un environnement de préproduction, sinon vous risquez de bloquer des fonctionnalités que vous ne surveillez pas au quotidien, formulaires, analytics, widgets.
Si vous mettez CSP, gardez aussi en tête que certains comportements, comme l’affichage de contenus embarqués, peuvent nécessiter des allowances ciblées. Le but n’est pas de rendre votre site “parfait”, mais de rendre l’exploitation plus difficile.
Nonces et autorisations: XSS n’est pas CSRF, mais tout se mélange vite
Il faut distinguer XSS et CSRF. XSS exécute du code dans le navigateur de la victime, alors que CSRF force une action à travers le navigateur. Les mitigations sont différentes.
Cependant, les attaques se cumulent. Si une XSS réussit, elle peut lire des tokens stockés en mémoire ou déclencher des requêtes sensibles. C’est pour cela que les bonnes pratiques WordPress sur nonces, capacités, et vérification côté serveur sont aussi une “barrière” contre l’impact.
Concrètement:
- les actions sensibles doivent vérifier une nonce les endpoints doivent vérifier les capacités (current_user_can()) les handlers doivent refuser les requêtes non autorisées
Une XSS qui ne peut déclencher aucune action utile devient moins intéressante pour l’attaquant. C’est une différence majeure entre “une charge qui s’affiche” et “une charge qui compromet”.
Surveiller et réduire ce qui change dans votre code: thèmes, plugins, et champs
Une protection WordPress solide ne dépend pas uniquement de votre code. Elle dépend aussi de votre hygiène d’écosystème.
Les plugins sont souvent à l’origine de bugs d’affichage quand ils ajoutent des shortcodes ou des paramètres de configuration qui finissent rendus dans le front. Les thèmes aussi, surtout les templates “custom”.
C’est tentant de dire “mettez tout à jour”. Oui, mais ça ne suffit pas à éviter des erreurs de logique. La mise à jour aide à corriger des vulnérabilités connues, mais une XSS peut naître d’un cas non couvert.
Ce que vous pouvez faire de manière pragmatique:
- limiter le nombre de plugins, chaque plugin est une surface désactiver et supprimer les plugins inutilisés revoir les paramètres qui sont affichés publiquement, même s’ils viennent du back-office exiger des mises à jour régulières pour les thèmes et plugins critiques
Et côté contenu, surveiller les champs qui autorisent du HTML. Un champ trop permissif dans un rôle qui n’est pas totalement de confiance est un risque réel.
Où se situe le “bon” compromis?
Souvent, les équipes veulent offrir aux auteurs la possibilité d’avoir du contenu riche. C’est compréhensible. Le compromis qui marche le mieux en général:
- les auteurs ont une autorisation de contenu limitée et filtrée les administrateurs ont plus de liberté, mais l’affichage est quand même échappé correctement les champs qui finissent dans des attributs ne doivent pas contenir de HTML
Si vous donnez la possibilité d’insérer du HTML partout, vous facilitez la tâche à un attaquant. S’il n’a pas besoin d’insérer du script, il cherchera un moyen d’abuser d’un attribut ou d’un contexte adjacent.
Tests et validation: comment vérifier qu’on n’est pas vulnérable
Vous pouvez tester sans “brûler” votre site. L’idéal est de faire un environnement de staging ou un clone de la base de production. Ensuite, testez les endroits où vos paramètres et champs sont affichés.
Je privilégie une logique: identifier le flux entrée vers sortie. Puis vérifier si le navigateur exécute ce qu’il ne devrait pas exécuter.
Voici deux scénarios de test courants, sans entrer dans des charges trop agressives:
- un paramètre d’URL affiché dans un titre, par exemple une recherche un champ de texte (ou un champ riche filtré) réinjecté dans une page article ou une page auteur
Le but est d’observer si la donnée est rendue comme du texte, ou si elle devient du markup interprété.
Une fois que vous corrigez, testez aussi la robustesse: si vous corrigez dans un template, vérifiez les autres chemins. Un contenu peut être réutilisé ailleurs, dans un widget, un bloc, une page de tag, un fil RSS, ou une page AMP si vous en utilisez.
Un exemple concret de correction sur un affichage risqué
Imaginons une situation simple: vous avez un champ “slogan” dans un thème, modifiable par l’administrateur ou un rôle. Dans un template, quelqu’un a écrit:
Si slogan contient du HTML ou une chaîne injectée, ce code affiche tel quel. La correction minimale est:
Si vous voulez autoriser un petit HTML, par exemple italique et liens, vous ne pouvez pas juste échappement texte. Vous nettoyez d’abord:
$clean = wp_kses( $slogan, [ 'em' => [], 'strong' => [], 'a' => [ 'href' => [], 'title' => [], 'target' => [], 'rel' => [], ], ] ); Echo $clean;
Mais même là, gardez en tête que la sortie doit être cohérente avec le contexte. Si vous réinjectez ensuite dans une URL ou dans un attribut, il faut d’autres fonctions.
Sur WordPress, la sécurité vient rarement d’une “fonction magique”. Elle vient de la combinaison entrée nettoyée, sortie échappée, et contexte respecté.
CSP et échappement: pourquoi les deux ensemble font gagner du temps
Quand on corrige une XSS, on peut aller vite sur un correctif ponctuel, surtout si on trouve exactement une sortie non échappée. La CSP arrive ensuite comme garde-fou.
Je l’ai vu fonctionner dans des cas où un correctif https://gardewp.fr/securite-wordpress/ serveur était partiel: une autre vue ou un autre template réinjectait la donnée ailleurs. La CSP limitait l’exécution et donnait le temps de trouver la sortie restante. Ce temps est précieux, surtout sur des sites à fort trafic, où chaque minute compte.
Le trade-off est clair: CSP demande une configuration soignée, et si vous la configurez trop strictement d’un coup, vous cassez des scripts légitimes. Mais si vous la construisez progressivement, elle apporte un filet qui compense les oublis.
Politique de rôles et réduction de l’exposition
Le meilleur “contrôle de risque” sur WordPress reste souvent de réduire qui peut insérer quoi. Un utilisateur qui peut publier ou modifier des champs affichés dans le front est déjà en position de créer du contenu malveillant si un contrôle de sortie est absent.
Je recommande de revoir vos rôles et vos capacités:
- est-ce que des rôles bas peuvent modifier des champs qui finissent directement dans du HTML ? est-ce que des éditeurs peuvent injecter du HTML non filtré ? est-ce que des auteurs peuvent ajouter des shortcodes ou des blocs dynamiques sans garde-fous ?
Une bonne règle opérationnelle: plus un rôle peut influencer le front, plus il faut que l’affichage soit strictement échappé et filtré.
Règles de décision simples que j’utilise
Si vous voulez formaliser sans vous compliquer la vie:
- Si la donnée est du texte, rendez-la comme du texte. Si la donnée est du HTML autorisé, nettoyez-la selon une whitelist, puis rendez-la dans un contexte compatible. Si la donnée est une URL, traitez-la comme une URL, pas comme du texte libre. Si vous ne savez pas le contexte final, ne rendez pas sans adaptation.
Ces décisions évitent 80 pour cent des surprises qu’on voit lors des incidents.
Mettre en place une routine de protection WordPress continue
La sécurité n’est pas un sprint. C’est une habitude. Sur des sites WordPress, elle s’organise autour de trois cycles: avant publication, au moment des changements, et après incident ou quasi-incident.
Je vous propose une routine courte, centrée sur le réel:
- Avant de déployer un thème ou un plugin maison, vérifier les sorties des champs qui peuvent contenir du contenu utilisateur. Après chaque mise à jour, faire un contrôle rapide des pages qui réinjectent des données, notamment recherche, auteur, tags, formulaires. Surveiller les logs et les comportements anormaux, car une XSS qui se déclenche laisse parfois des traces indirectes, visites étranges, paramètres ajoutés, appels vers des URLs inattendues.
Si vous avez un scanner ou un outil de sécurité, utilisez-le comme un signal. Un scan peut dire “potentiel”, mais la correction dépend de votre contexte. La vérité, c’est ce que le navigateur fait réellement.
En cas de suspicion: quoi faire sans paniquer
Si vous suspectez une XSS, évitez deux réflexes: supprimer au hasard, ou bloquer tout sans comprendre.
Le bon ordre de bataille est pragmatique:
- Identifier le vecteur, quel champ, quel paramètre, quel modèle de page. Reproduire en local ou en staging quand c’est possible. Corriger la sortie avec l’échappement ou le filtrage adapté au contexte. Ajouter une couche de défense comme CSP si le site s’y prête. Vérifier aussi les pages “secondaires” qui réutilisent la même donnée.
Une XSS stockée exige souvent aussi de nettoyer les contenus corrompus, pas uniquement de corriger le code. Sinon, la faille reste active pour les personnes qui consultent les contenus déjà injectés.
Ce que j’attends d’une vraie protection WordPress contre l’XSS
Quand une équipe me demande “comment on se protège”, je résume souvent la réponse en une phrase: vous rendez chaque donnée non fiable inoffensive au moment où vous l’affichez, puis vous limitez l’exécution côté navigateur, et vous réduisez les possibilités d’action après exécution.
C’est exigeant, mais c’est réaliste. WordPress vous donne les fonctions nécessaires, il faut juste les appliquer au bon contexte. Et si vous ajoutez CSP, vous couvrez les oublis inévitables quand le site grandit, plugins, blocs, templates, nouvelles pages.
Si vous ne deviez retenir qu’un axe, c’est celui-ci: l’échappement de sortie n’est pas un détail d’implémentation. C’est le cœur de la protection contre XSS sur WordPress.
Si vous souhaitez, décrivez-moi votre cas concret (type de champ ou page concernée, thème ou plugin utilisé, et ce que vous affichez). Je peux vous proposer une stratégie de correction adaptée au contexte exact, avec les fonctions WordPress pertinentes.