XML-RPC, c’est un vieux morceau de WordPress, utile à certaines intégrations, mais devenu une cible récurrente. Sur beaucoup de sites, les tentatives d’abus ne ressemblent pas à un “grand piratage” spectaculaire. Elles ressemblent plutôt à un bruit persistant: des appels répétés, parfois avec des noms d’utilisateur probables, parfois avec des paramètres étranges, souvent avec une intention de forcer l’authentification ou d’exploiter un comportement inattendu.
Si votre objectif est une sécurisation WordPress réaliste, le sujet XML-RPC mérite qu’on s’y attarde sérieusement. Limiter l’attaque sur cette interface, c’est réduire une surface d’entrée, diminuer la charge inutile, et surtout gagner en tranquillité quand les bots tournent sans relâche.
Pourquoi XML-RPC attire les attaquants
XML-RPC est une API WordPress qui permet à un client externe (ancienne fonctionnalité, apps, scripts, certains plugins) d’effectuer des opérations à distance via des appels HTTP contenant du XML. Le point sensible, c’est que cette API peut déclencher des traitements côté serveur avant même que l’utilisateur ne soit pleinement authentifié, selon la méthode appelée et la configuration.
Dans les logs, ça donne souvent un schéma: des requêtes sur le chemin typique /xmlrpc.php avec des payloads variés, parfois en rafale. Quand un attaquant cherche à tester des mots de passe, il passe par une interface qui peut répondre différemment selon les erreurs. La différence de réponse, même subtile, aide à améliorer la stratégie. Ajoutez à cela le fait que WordPress a longtemps eu un écosystème large, donc beaucoup de clients légitimes (ou “historiquement légitimes”), et vous obtenez un terrain propice aux tentatives automatiques.
Un autre facteur pratique: XML-RPC est facile à repérer. L’URL est connue, la méthode à appeler est identifiable, et les frameworks d’attaque savent la forcer. Même quand le taux de succès est faible, le volume suffit à générer du bruit et à amplifier les risques, y compris l’usure de ressources serveur et le déclenchement de mécanismes de défense trop tardifs.
Ce que vous risquez concrètement si XML-RPC reste accessible
Je ne vais pas promettre des chiffres universels, car chaque parc a ses particularités. Mais sur le terrain, les impacts suivent des patterns assez stables.
- Attaques par force brute ciblées sur l’authentification: si XML-RPC est accessible, un bot peut tenter des couples identifiant/mot de passe via l’API plutôt que directement sur le formulaire classique. Déclenchement de mécanismes de détection: certains sites se retrouvent à activer des protections (ratelimit, WAF, anti-bot) qui finissent par pénaliser des requêtes légitimes, simplement parce que le volume XML-RPC est élevé. Charge inutile: même quand l’attaque échoue, le serveur traite la requête, parse du XML, exécute des contrôles applicatifs. À l’échelle d’un petit hébergement, cela peut contribuer à dégrader les performances. Exposition à des erreurs spécifiques: selon la version, la configuration et la chaîne de plugins, certaines méthodes peuvent déclencher des comportements qu’on n’aurait jamais eus via l’interface web standard.
Le plus important, c’est qu’on n’a pas besoin d’attendre une “faille” au sens strict pour que l’ouverture de l’API pose problème. La simple disponibilité d’un point d’entrée connu, couplée à des tentatives automatisées, suffit à augmenter le risque global.
Vérifier si vous avez vraiment besoin de XML-RPC
Avant de “couper”, il faut être sûr que vous ne cassez pas des usages légitimes. C’est là que beaucoup d’administrateurs se font surprendre. WordPress a longtemps été utilisé avec des apps mobiles, certains outils de publication, ou des connexions d’anciens plugins.
J’ai vu des cas typiques:
- Un client iPhone ou Android qui synchronise des publications via un client compatible XML-RPC. Un outil de monitoring ou un script interne qui republie du contenu. Un plugin historique qui utilise XML-RPC pour certaines tâches, parfois sans documentation claire.
La manière la plus fiable est de combiner lecture des usages applicatifs et observation du trafic. Si vos logs n’ont aucun appel XML-RPC légitime depuis longtemps, la probabilité que vous en ayez besoin est faible. Mais ce n’est pas une preuve. Une équipe peut arrêter un plugin sans supprimer les réglages d’un outil, ou changer d’app sans mettre à jour une configuration.
Sur un parc correctement documenté, on peut aussi faire un petit audit: chercher dans le code et les plugins actifs, voir si XML-RPC est invoqué, et vérifier si un client externe est en place. Ce n’est pas glamour, mais c’est le genre de travail qui évite une panne fonctionnelle le lendemain.
Deux stratégies: limiter ou fermer (et pourquoi ça change tout)
Quand on parle de “limiter les attaques sur XML-RPC”, on a en général deux écoles:
Limiter: conserver l’API pour les usages légitimes, mais réduire l’impact des tentatives automatisées. Fermer: désactiver XML-RPC si vous n’en avez pas besoin.Le bon choix dépend de vos contraintes. Fermer réduit la surface d’attaque de façon nette, mais risque de casser un usage. Limiter conserve la compatibilité, mais peut laisser un peu d’exposition, notamment si la limitation n’est pas suffisamment stricte.
La plupart des sites qui n’ont pas besoin de XML-RPC peuvent le désactiver sans douleur. Sur ceux qui en ont besoin, il faut alors miser sur une approche défensive plus fine.
Quels signes d’attaques sur XML-RPC dans vos logs
Si vous avez accès aux logs web (Nginx, Apache, reverse proxy) ou à des logs applicatifs WordPress, vous pouvez confirmer que XML-RPC est effectivement ciblé. Voici ce que je cherche le plus souvent, pas comme “preuves absolues”, mais comme signaux forts.
Requêtes répétées sur /xmlrpc.php avec des tailles de payload XML très variables. Tentatives en rafale, parfois avec des délais quasi constants, typiques d’un bot. Beaucoup d’erreurs d’authentification en peu de temps (selon votre mode de journalisation). User agents génériques ou incohérents, ou au contraire absence de user agent. Des codes HTTP qui restent souvent dans les mêmes catégories (souvent 401/403 côté défense, ou 200 si l’application répond tout de même).Si vous observez ce pattern, vous avez une bonne base pour justifier une réduction de surface. Et si le volume est faible mais régulier, une limitation pourrait suffire.
Désactiver XML-RPC: le levier le plus direct
Désactiver XML-RPC est souvent la meilleure option quand vous n’en avez pas besoin. WordPress fournit un point d’entrée clair: xmlrpc.php. Vous pouvez soit le désactiver côté WordPress, soit le bloquer au niveau serveur.
Désactivation dans WordPress
Selon votre contexte, vous pouvez utiliser un plugin de sécurité ou une règle applicative. L’approche “plugin” est pratique, mais elle ajoute une dépendance: vous devez gérer la mise à jour et la compatibilité. L’approche “code” (filtre ou condition dans WordPress) demande plus de rigueur, surtout si vous maintenez un thème custom ou un mu-plugin. Dans tous les cas, l’objectif est le même: empêcher l’exécution des méthodes XML-RPC.
Ce que j’aime dans la désactivation applicative, c’est le contrôle fin. Vous pouvez, par exemple, refuser toutes les requêtes sauf celles provenant d’une liste d’IP de confiance, ou refuser uniquement certaines méthodes. Mais plus vous implémentez des règles, plus vous devez tester.
Blocage au niveau serveur (Nginx ou Apache)
Le blocage au niveau serveur est souvent plus “simple” et plus robuste contre les contournements applicatifs, car la requête ne traverse pas WordPress. En Nginx ou Apache, vous pouvez renvoyer un code d’erreur, ou carrément couper la connexion. Le bon code dépend de votre politique. Parfois, renvoyer 403 calme les bots, parfois 404 limite l’information.
Un détail qui compte: si vous avez un reverse proxy ou un WAF en amont, il peut déjà intercepter une partie du trafic. Bloquer au niveau serveur en plus peut sembler redondant, mais ça réduit la charge et évite que la requête atteint le runtime PHP.
Le trade-off principal: les usages légitimes
La partie la plus délicate n’est pas technique, elle est opérationnelle. La désactivation doit être alignée avec votre écosystème: apps, plugins, scripts. Si vous désactivez sans vérifier, vous risquez des symptômes “bizarres” côté utilisateur: publication qui ne se synchronise plus, ping qui échoue, import automatique interrompu.
C’est pour ça que je recommande de planifier un test. Même un simple test interne sur un client existant et un contrôle dans les logs après changement peuvent éviter 90% des surprises.
Si vous devez conserver XML-RPC: limitez proprement
Parfois, vous ne pouvez pas couper. Un client externe dépend de l’API, ou un outil interne est plus ancien. Dans ce cas, “limiter” est la bonne approche, mais elle doit être plus qu’un simple coupage temporaire.
L’idée est de réduire la fenêtre pour les tentatives automatisées, sans empêcher les clients légitimes.
Voici une stratégie pragmatique, celle que j’ai tendance à recommander quand l’API doit rester accessible:
Ratelimit par IP sur /xmlrpc.php (et idéalement aussi sur les chemins associés si vous avez du bruit ailleurs). Blocage ou challenge WAF pour les patterns de bots évidents, sans viser le trafic normal. Filtrage par authentification pour limiter l’intérêt d’essayer des couples de mots de passe via XML-RPC. Limiter aux méthodes réellement nécessaires si vous contrôlez la couche applicative. Surveillance avec alertes quand le volume dépasse un seuil.Selon votre stack, ces points peuvent être appliqués via WordPress, via un plugin, via un WAF, ou via le reverse proxy.
Ratelimit: utile, mais attention au faux positif
Le ratelimit aide beaucoup, parce que les bots ont tendance à tenter de manière répétitive. Mais attention: si un client légitime fait des synchronisations fréquentes (par exemple, un agent qui interroge trop souvent), il peut se retrouver “bridé” et provoquer des symptômes que les utilisateurs interprètent comme un problème WordPress, pas comme un anti-abus.
Le compromis consiste à choisir des seuils réalistes. Sur un site petit ou moyen, des seuils trop agressifs posent vite problème. Sur un site très exposé, des seuils plus stricts sont acceptables. Il faut donc observer, puis ajuster.
WAF et règles de détection: efficace si vos patterns sont propres
Un WAF peut détecter les requêtes anormales sur XML-RPC grâce à des signaux: tailles de payload, répétition de méthodes, absence de certains en-têtes, patterns d’erreur. L’avantage, c’est que vous pouvez le faire sans toucher au code WordPress.
L’inconvénient, c’est que les règles trop générales finissent par bloquer des clients “limites” mais légitimes. Le bon réglage est un travail d’ajustement: commencer large, observer les logs d’événements, puis resserrer.
Une approche “propre” côté WordPress: mu-plugins et contrôle fin
Si vous gérez WordPress en profondeur, une approche plus maîtrisée consiste à utiliser un mu-plugin (plugin must-use). L’intérêt est simple: vous chargez un code minimal, que vous contrôlez, et qui s’exécute avant les thèmes et la majorité des plugins.
Vous pouvez y implémenter une logique qui refuse XML-RPC selon des conditions, par exemple:
- refus global si vous n’avez pas besoin de XML-RPC, ou refus sauf pour certaines IP, ou refus pour certaines méthodes.
Le point important est de tester sur votre instance de staging, parce que WordPress charge des choses de façon spécifique. Et si vous avez un fournisseur d’hébergement qui modifie la config, le comportement peut changer.
Je préfère cette méthode quand je veux une règle stable et versionnée, plutôt qu’un bouton dans un plugin de sécurité qui change de comportement au gré des mises à jour.
Hardsening autour de XML-RPC: réduire les chances d’attaquer le bon endroit
Limiter XML-RPC ne suffit pas à lui seul. C’est une réduction de surface, pas un bouclier magique. Mais elle se combine bien avec des mesures de sécurité “classiques” qui rendent l’attaque plus coûteuse.
Par exemple, si vos identifiants sont protégés et que vos comptes admin n’ont pas de mots de passe faibles, l’impact d’une tentative de force brute via XML-RPC diminue. Si vous limitez l’essai de mots de passe (au niveau application ou via un plugin), vous réduisez la rentabilité du bot.
Côté durcissement, je pense aussi à:
- des listes de comptes sensibles sans mot de passe simple, une gouvernance des rôles, et une hygiène de plugins (suppression des plugins inutiles, mises à jour à jour).
Ce n’est pas glamour, mais c’est là que les incidents se gagnent ou se perdent.
Tester après changement: ce que j’observe en pratique
Après une modification visant XML-RPC, je fais trois vérifications, assez simples.
1) Je vérifie immédiatement que les pages du site répondent normalement, et que les fonctions critiques ne dépendent pas d’une synchro XML-RPC.
2) Je regarde les logs pendant une période courte, typiquement quelques heures. Si j’ai bloqué XML-RPC, je dois voir la réduction du bruit sur /xmlrpc.php. 3) Je fais un test fonctionnel sur les outils qui étaient censés dépendre de XML-RPC. Si vous avez un client mobile ou un outil externe, c’est maintenant qu’on le découvre.Sur le terrain, les problèmes apparaissent souvent dans les heures qui suivent le changement, pas deux semaines après. Un test rapide, et un retour sur logs, valent largement le temps investi.
Exemple de décision: couper ou limiter sur un site avec “un peu d’héritage”
Un cas réel, même si je simplifie volontairement: vous reprenez un site WordPress qui a tourné pendant des années. Il y a encore des plugins installés “parce que ça marche”, et personne ne sait exactement pourquoi. Les logs montrent des tentatives répétées sur /xmlrpc.php, mais le site n’a pas de gros trafic.
Dans ce contexte, la décision que je prends souvent ressemble à ceci, en deux étapes:
- D’abord, vérifier rapidement si un client externe est en place. Un simple audit interne, et parfois un coup d’œil dans les configurations des outils connectés, suffit. Ensuite, soit désactivation directe si rien ne dépend de XML-RPC, soit limitation contrôlée si un usage est confirmé.
Cette approche évite le “tout couper du jour au lendemain” quand on a un doute raisonnable. Et elle évite aussi de laisser XML-RPC ouvert par habitude alors qu’il ne sert à rien.
Mettre en place une surveillance utile (sans noyer l’équipe)
Une fois XML-RPC réduit, vous gagnez en signal. Au lieu de regarder un volume https://gardewp.fr/securite-wordpress/ énorme de tentatives, vous pouvez suivre un indicateur plus stable: les requêtes sur /xmlrpc.php et les erreurs associées.
L’objectif n’est pas d’être parano, c’est d’avoir une alerte utile. Si le volume remonte soudainement après avoir été calme, c’est souvent le signe que:
- un bot reprend l’attaque, ou une régression s’est produite dans vos règles, ou un changement serveur a modifié la manière dont les protections renvoient les réponses.
Sur un site géré sérieusement, une alerte de volume ou une alerte sur codes HTTP inhabituels est plus pertinente qu’une alerte “au moindre 404”. Vous réduisez le bruit, vous gardez l’information.
Les erreurs fréquentes à éviter
Ce sont des erreurs que j’ai vues revenir souvent quand on parle de sécurisation WordPress autour de XML-RPC.
- Désactiver sans vérifier les usages: un client externe ne répond plus, et l’équipe passe du temps à chercher “où ça bloque” dans WordPress, alors que la cause est un choix de sécurité. Limiter sans mesurer: vous mettez un ratelimit agressif, les utilisateurs légitimes subissent des erreurs intermittentes, et la confiance envers la sécurité baisse. Compter uniquement sur un plugin: un plugin change, une configuration dérive, et la protection ne fait plus ce qu’on croit. Si possible, la règle doit être documentée et reprise dans vos procédures. Ne pas ajuster les seuils après coup: la première version d’une règle n’est presque jamais parfaite. Les bots changent, vos habitudes de trafic aussi.
Le bon réflexe, c’est de traiter XML-RPC comme une pièce dans un puzzle. Vous réduisez l’exposition, puis vous ajustez selon les logs.
Conclusion opérationnelle: gagner du temps et de la sérénité
Limiter les attaques sur XML-RPC, ce n’est pas une question de mode, c’est une question de surface d’entrée. Quand une cible est connue, accessible et régulièrement attaquée, réduire son exposition est souvent le meilleur retour sur investissement.
Si vous n’utilisez pas XML-RPC, désactivez-le proprement, idéalement en combinaison avec une surveillance. Si vous devez le conserver, limitez l’accès et appliquez des règles capables de distinguer le bruit automatisé d’un usage légitime.
Le résultat, dans la vraie vie, se mesure rarement en “grand événement”. Il se mesure plutôt en baisse du bruit dans les logs, en réduction de charge côté serveur, et en moins d’heures passées à diagnostiquer des comportements déclenchés par des tentatives de bots. C’est exactement ce qu’on veut quand on gère un WordPress durable, et qu’on cherche une sécurisation WordPress pragmatique, pas un empilement de mesures difficiles à maintenir.