XML-RPC, c’est un vieux protocole de WordPress, conçu pour permettre des appels à distance, notamment pour publier, gérer du contenu et intégrer des clients externes. Aujourd’hui, cette même ouverture https://gardewp.fr/securite-wordpress/ en fait une cible régulière pour des essais de connexion, des attaques par force brute et des tentatives d’abus. Le point intéressant, c’est que dans beaucoup de sites, XML-RPC n’apporte rien au quotidien. Le couper, c’est souvent gagner en surface d’attaque sans toucher au cœur du site.
Mais le piège, c’est la “coupure au hasard”. Sur certains environnements, certaines briques (applications de publication, outils d’automatisation, intégrations historiques) reposent encore sur l’endpoint xmlrpc.php. Si on désactive trop vite, on ne casse pas seulement une fonction “inutile”, on peut aussi casser une intégration discrète. La bonne approche consiste à décider, puis à désactiver proprement, et surtout à valider avant de déclarer la victoire.
Comprendre ce que vous désactivez vraiment
L’endpoint principal s’appelle xmlrpc.php. C’est une URL “plate” à laquelle des requêtes HTTP sont envoyées. Le risque vient du fait que ce point d’entrée peut être exploité pour tenter des connexions et interroger WordPress selon des schémas connus des attaquants. Sur des sites WordPress exposés à Internet (et donc accessibles depuis l’extérieur), un attaquant n’a pas besoin de trouver une faille dans le code, il peut simplement appeler cet endpoint de manière répétée.
Quand vous désactivez XML-RPC, vous ne supprimez pas WordPress, ni la page d’administration, ni l’API REST. Vous bloquez une route spécifique, ce qui réduit la surface d’attaque. En revanche, vous devez accepter le compromis suivant : si une partie de votre écosystème dépend de XML-RPC, vous perdrez ce fonctionnement.
Sur beaucoup de sites, la majorité des opérations passent par le navigateur, par l’API REST ou par des flux internes. Dans ce cas, désactiver XML-RPC est un geste de sécurisation WordPress très pragmatique. Sur d’autres, notamment les sites qui ont été “touchés” à plusieurs reprises au fil des années, il peut exister une dépendance ancienne et oubliée.
Un repère utile : si vous n’utilisez aucune application externe pour publier (mobile, outil de synchronisation, CMS externe, anciennes intégrations), vous êtes probablement bon. Si vous pilotez WordPress via des scripts ou des modules tiers, il faut vérifier.
Le moment où ça casse, et pourquoi
Désactiver XML-RPC peut provoquer des symptômes parfois déroutants, car ils ressemblent à des problèmes d’identifiants ou de droits. Par exemple :
- un client de publication distant signale une erreur générique de connexion ou d’authentification alors que vos identifiants fonctionnent dans l’interface classique ; un outil d’automatisation ne déclenche plus ses actions de publication ou de mise à jour ; des fonctionnalités de notifications historiques ne réagissent plus comme attendu.
Le diagnostic exact dépend du client. Certains retours d’erreur sont clairs (“endpoint inaccessible”, “404”, “403”), d’autres ressemblent à un échec de requête. C’est pour cela que je recommande de valider avant de couper définitivement, et de savoir comment réactiver rapidement.
Il y a aussi un point de méthode. Dans certains hébergements, vous pouvez simplement “refuser” les requêtes. Dans d’autres, vous pouvez faire renvoyer un code HTTP précis. Le choix du code a une importance opérationnelle : si vous renvoyez un 404, vous rendez la ressource moins visible, mais côté logs, vous pouvez perdre une partie de la signalisation. Si vous renvoyez un 403, vous indiquez clairement que c’est interdit, ce qui simplifie parfois l’analyse.
Avant de désactiver : vérifier les dépendances sans y passer la journée
Je préfère une préparation courte, mais réelle. Elle évite le syndrome “ça cassait, mais je ne sais pas quoi”.
Voici un mini-cadre de vérification, sans promesse magique, juste du bon sens opérationnel :
Cherchez dans votre historique d’outils ce qui touche à la publication ou à la synchronisation externe (scripts, apps mobiles, intégrations CMS, plugins d’automatisation). Consultez les plugins installés qui communiquent avec l’extérieur (certains modules utilisent des routes spécifiques pour la mise à jour, l’échange de contenu ou la publication). Vérifiez les logs web (au moins sur quelques jours) pour xmlrpc.php : si vous voyez beaucoup d’appels “normaux”, c’est un signe d’utilisation, et vous devez enquêter avant de couper. Faites un test contrôlé sur une zone de pré-production ou, à défaut, avec un faible risque de rollback (en gardant la capacité de reconfigurer rapidement). Planifiez un créneau où vous pouvez répondre à un éventuel incident dans l’heure suivante.Cette étape est surtout un “filet de sécurité”. Si vous coupez un système qui dépend de XML-RPC, le problème n’est pas la théorie, c’est la dépendance cachée.
Choisir la bonne méthode pour désactiver XML-RPC
Il existe plusieurs façons d’obtenir le résultat. Les plus courantes passent par un plugin de sécurité, ou par une règle au niveau du serveur web. Chacune a ses avantages.
Désactiver via un plugin est souvent simple et réversible. Vous appliquez une règle, et vous retrouvez l’endpoint bloqué sans toucher à la configuration serveur. C’est confortable, mais ça ajoute une couche logicielle de plus. Si vous êtes en environnement minimal et que vous cherchez de la robustesse, vous préférerez parfois le blocage au niveau du serveur.
Désactiver via .htaccess ou configuration Nginx est très efficace et souvent plus “dur”, car c’est le serveur qui refuse la route avant que WordPress ne soit même consulté. L’inconvénient, c’est que vous devez connaître votre stack (Apache, Nginx, ou un proxy en amont) et manier les règles proprement.
Et puis il y a une autre réalité : certains hébergeurs fournissent leurs propres mécanismes de filtrage. Dans ce cas, suivre la documentation de l’hébergeur est souvent le meilleur chemin, parce que la règle exacte et l’endroit exact peuvent différer.
Désactivation au niveau du serveur avec Apache (via .htaccess)
Si votre site tourne derrière Apache et que vous pouvez modifier .htaccess, vous pouvez bloquer directement l’accès à xmlrpc.php. L’idée est de renvoyer un code qui indique “interdit” ou “introuvable”, selon votre préférence.
Une règle typique consiste à matcher l’URI exacte /xmlrpc.php et à refuser les requêtes. L’avantage, c’est que c’est rapide, et que WordPress n’est pas appelé. C’est aussi ce qui réduit le bruit dans les logs applicatifs.
Quelques conseils de prudence :
- appliquez la règle dans le bon répertoire, celui qui correspond au root WordPress ; vérifiez si vous avez des règles existantes (par exemple des redirections, des protections anti-bot) pour éviter les conflits ; gardez une sauvegarde de .htaccess, et testez après modification.
Je ne vous impose pas un code HTTP précis ici, parce que cela dépend de votre stratégie de sécurité et de votre lecture des logs. Dans la pratique, “403 interdit” aide souvent à comprendre ce qui se passe, tandis que “404 introuvable” peut réduire la visibilité de l’existence de l’endpoint.
Après ajout, testez immédiatement en appelant l’URL concernée depuis l’extérieur de votre réseau. Un navigateur suffit, mais un outil de requête (comme un client HTTP en ligne ou en ligne de commande) permet de vérifier le code exact et les en-têtes renvoyés.
Désactivation au niveau du serveur avec Nginx
Sur Nginx, vous pouvez bloquer l’emplacement xmlrpc.php à la racine du site. Ici aussi, l’objectif est identique : refuser avant que la requête ne soit transmise à PHP.
L’enjeu technique porte surtout sur le contexte de votre configuration. Certaines personnes modifient directement le server block, d’autres utilisent des include séparés, ou passent par un reverse proxy. Si vous appliquez la règle au mauvais endroit, vous pouvez obtenir une “fausse victoire” où la règle ne s’applique pas.
Une vérification utile consiste à regarder les logs d’accès Nginx après activation. Si les requêtes vers xmlrpc.php disparaissent des logs PHP et apparaissent dans les logs Nginx avec le code attendu, c’est bon signe.
Si vous avez Cloudflare ou un autre pare-feu en amont, la logique change un peu : vous pouvez décider de bloquer côté fournisseur ou côté origine. Dans ce cas, je recommande de tracer où la requête est réellement stoppée, pour ne pas croire que l’origine est protégée alors que tout est géré par un filtrage externe.
Désactivation via un plugin de sécurité
Les plugins de sécurité offrent souvent une option “Disable XML-RPC” ou une règle équivalente. Leur force, c’est la simplicité. Leur faiblesse, c’est la dépendance à un outil additionnel, et la difficulté occasionnelle à comprendre exactement quelle règle est injectée et où.
J’aime bien les plugins quand ils s’intègrent proprement à une stratégie globale : durcissement des pages d’authentification, limitations de tentatives, filtrage des endpoints, durcissement HTTP. Mais pour “désactiver XML-RPC en toute sécurité”, il faut au minimum :
- confirmer que la désactivation s’applique bien à xmlrpc.php et pas seulement à certains formats de requête ; vérifier le comportement du code HTTP renvoyé ; tester l’absence d’effet secondaire sur votre process de publication.
Dans un environnement où vous tenez à la reproductibilité (par exemple plusieurs sites gérés avec la même base), une stratégie serveur est souvent plus homogène. Dans un environnement plus “artisan”, le plugin peut être le chemin le plus rapide pour réduire le risque sans plonger dans la configuration.
Tester après modification, sans se mentir
Le test ne doit pas être une “vérification légère”. Une règle mal placée, un conflit de priorités, ou une restriction qui ne s’applique qu’à certaines routes, et vous pensez avoir sécurisé alors que l’endpoint répond toujours.
Je fais ces tests à chaque fois, surtout quand je touche au serveur :
Appel direct à https://votre-domaine/xmlrpc.php depuis l’extérieur, en vérifiant le code HTTP (et si possible la réponse). Vérification des logs : est-ce que les requêtes n’atteignent plus WordPress (logs PHP) et restent au niveau serveur ? Tests “métier” : publication depuis l’interface WordPress, ajout d’un brouillon, mise à jour d’un contenu. Test des intégrations : tout ce qui publie ou synchronise depuis l’extérieur doit être revalidé, même rapidement. Surveillance sur 24 à 48 heures : regarder s’il reste des tentatives, et si vos outils internes ne déclenchent pas d’erreurs.Même si vous êtes sûr de votre configuration, un suivi court après changement vaut de l’or.
Cas particuliers : quand vous ne devez pas désactiver sans nuance
Il y a des situations où je ralentis volontairement.
Si vous utilisez une application ou un plugin de publication distante, XML-RPC peut être utilisé comme canal. Même si votre site “a l’air de marcher” une partie du temps, certains scénarios peuvent échouer plus tard. Exemple typique : un outil qui planifie des publications via un mécanisme historique, et qui n’essaie pas de publier à chaque page consultée.
Autre cas : les sites multi-utilisateurs avec des workflows internes. Si un contributeur travaille sur mobile ou via une interface externe spécifique, la désactivation peut avoir un impact réel sur la production, pas seulement sur la sécurité.
Enfin, certains environnements “legacy” reposent sur des intégrations anciennes. Quand vous héritez d’un site créé il y a plusieurs années, vous ne savez pas toujours quels modules ont été ajoutés, puis abandonnés. Désactiver sans vérifier, c’est risquer de découvrir le problème la veille d’une publication importante.
La règle que j’utilise : si vous n’avez pas la certitude qu’aucune intégration externe n’a besoin de XML-RPC, vous pouvez d’abord observer vos logs. S’il n’y a jamais d’accès, ou presque, l’impact sera probablement faible. S’il y a des accès réguliers, enquêtez.
Relancer et revenir en arrière : la sécurité, c’est aussi le rollback
Un bon durcissement ne s’arrête pas au “ça marche”. Il inclut le plan de retour.
Concrètement, avant de désactiver :
- gardez une copie de vos fichiers modifiés (.htaccess, include Nginx, fichier de configuration serveur) ; notez la date, l’heure, et le contenu de la modification ; prévoyez un chemin simple pour rétablir l’accès à xmlrpc.php.
Après coup, si un outil tombe en panne, le plus frustrant est de ne pas pouvoir identifier la cause rapidement. Si votre rollback est facile, vous répondez en minutes plutôt qu’en heures.
Ajuster la posture globale de sécurité, pour que XML-RPC ne soit qu’un maillon
Désactiver XML-RPC réduit une partie du risque, mais ne remplace pas une bonne hygiène.
En pratique, je vois des sites devenir plus “tranquilles” dès qu’ils combinent plusieurs couches : limitation des tentatives de connexion, durcissement des pages sensibles, gestion des mots de passe, mises à jour régulières, et surveillance des logs. Le point clé est de traiter WordPress comme un système vivant, pas comme un fichier qu’on “verrouille une fois”.
Même si ce guide se concentre sur XML-RPC, je considère la désactivation comme une correction ciblée, pas une solution unique. Si votre sécurité dépend uniquement d’un endpoint bloqué, vous allez sentir le jour où un autre vecteur trouve sa place.
Vérifier que vous n’avez pas introduit d’effet secondaire
Un blocage serveur peut parfois affecter d’autres chemins si la règle est mal formulée. C’est rare quand on cible l’URI exacte xmlrpc.php, mais ça arrive avec des patterns trop larges, ou des règles d’erreur trop agressives.
Le test fonctionnel doit couvrir au moins l’essentiel : connexion à l’administration, sauvegarde d’un brouillon, publication d’un contenu, et vérification d’un écran de thème ou d’élément dynamique qui appelle des ressources (sans confondre, le but est de s’assurer que vous n’avez pas cassé PHP ou la redirection).
Si vous utilisez un CDN ou un WAF en amont, vérifiez aussi que les règles n’entrent pas en conflit. Parfois, une règle côté fournisseur renvoie une page HTML différente, ce qui peut masquer un problème de configuration côté origine. Là encore, les logs vous sauvent.
Résumé opérationnel
Désactiver XML-RPC est une mesure de sécurisation WordPress souvent efficace, surtout quand vous n’utilisez pas d’applications ou d’intégrations qui s’en servent. La clé, c’est l’ordre des actions : décider après vérification, appliquer la règle au bon endroit, tester le comportement, puis surveiller après changement.
Si vous avez besoin d’un point d’ancrage, gardez cette logique : bloquer xmlrpc.php le plus tôt possible dans la chaîne (idéalement au niveau serveur), vérifier par logs et tests fonctionnels, et garder un rollback simple.
Si vous me décrivez votre contexte (Apache ou Nginx, hébergeur, présence d’un reverse proxy type CDN, et si vous utilisez une application mobile ou des outils d’automatisation), je peux vous proposer une stratégie plus précise, avec la forme de règle la plus adaptée.
