Désactiver XML-RPC sur WordPress : pourquoi et comment

🔎 XML-RPC, c'est quoi dans WordPress

XML-RPC est un protocole qui permet à des programmes d'appeler WordPress à distance : publier un article, lister les posts, authentifier un utilisateur. Historiquement, les apps WordPress iOS et Android, Jetpack, certains outils de publication s'appuyaient dessus. Le fichier exposé s'appelle xmlrpc.php, à la racine du site.

L'API REST WordPress a pris le relais pour une grande partie des usages modernes. XML-RPC reste activé par défaut sur beaucoup d'installations, « au cas où ». Ce au cas où est une surface d'attaque documentée depuis des années.

🛠️ Pourquoi les bots adorent xmlrpc.php

XML-RPC permet d'essayer des mots de passe, parfois plusieurs à la fois (system.multicall), ce qui amplifie le brute-force. Ça génère de la charge, ça remplit les logs, ça peut ralentir un petit hébergement. Ce n'est pas théorique : c'est le quotidien des access.log WordPress.

Fermer XML-RPC ne remplace pas un mot de passe fort ni la double authentification. Ça enlève une rampe d'accès parallèle à wp-login.php. Les trois se cumulent. Un seul des trois, c'est mieux que rien. Les trois, c'est une TMA sécu de base.

✅ Qui s'en sert encore : la liste de contrôle avant de couper

Jetpack, selon les modules. Les apps mobiles officielles, si quelqu'un publie encore depuis le téléphone via l'ancien canal. IFTTT, Zapier et certains outils de planification. Des plugins de sauvegarde ou de stats anciens. Un prestataire qui pousse du contenu via un script 2016.

Je vous demande : qui publie autrement que par le navigateur ? On regarde les logs de xmlrpc.php : y a-t-il des appels légitimes (user-agent connu, IP du bureau) ou seulement des scans ? On coupe d'abord en préprod. On prévient le jour J. On a un rollback d'une ligne.

• Jetpack et modules qui parlent encore en XML-RPC
• Apps mobiles WordPress encore utilisées
• Automations (IFTTT, scripts, outils de rédaction)
• Logs : trafic légitime vs scan

⚠️ Comment désactiver XML-RPC proprement

Côté WordPress : un filtre add_filter('xmlrpc_enabled', '__return_false') dans un mu-plugin (extension obligatoire) ou le thème enfant. C'est clair, versionné, réversible. Les plugins « sécurité » le font aussi, parmi 40 autres options. Je préfère le geste explicite : on sait ce qui est coupé.

Côté serveur : renvoyer 403 ou 404 sur /xmlrpc.php (Nginx location, règle Apache). C'est plus radical : WordPress ne voit même plus la requête. Utile si la charge des bots est déjà un problème. On documente la règle, sinon le prochain prestataire passera une heure à chercher pourquoi « l'app ne se connecte plus ».

📌 À ne pas confondre avec l'API REST

Couper XML-RPC ne coupe pas /wp-json/. L'API REST a ses propres enjeux (utilisateurs, applications, headless). On ne les mélange pas. Un site headless a besoin de REST (ou de GraphQL). Il n'a en général pas besoin de XML-RPC.

Si vous durcissez, traitez REST à part : authentification, CORS, ce qui est public. Fermer XML-RPC n'est pas « fermer WordPress aux API ». C'est fermer un protocole ancien.

🧭 Tester après désactivation

xmlrpc.php doit répondre 403/404 ou un XML d'erreur selon la méthode. L'admin web fonctionne. Les publications Gutenberg aussi. Les formulaires aussi. Si Jetpack se plaint, on a un diagnostic, pas une surprise client. L'app mobile : on ouvre, on tente une action. Cinq minutes. On les prend.

On surveille 24 h les logs et les tickets « je n'arrive plus à publier ». Puis on range le geste dans la liste de durcissement du site, avec la 2FA et l'URL d'admin.

💡 Et si quelqu'un en a encore besoin

On restreint par IP plutôt que de laisser le monde entier. On migre l'usage vers l'API REST ou une app moderne. On ne garde pas XML-RPC ouvert « pour un stagiaire qui a l'app ». Le coût en scans dépasse le confort.

Les exceptions se documentent. Une TMA qui hérite d'un WordPress doit pouvoir lire : XML-RPC off depuis telle date, sauf telle IP pour tel outil. Sans ça, quelqu'un le réactivera « pour tester » et oubliera.

🧪 Place dans une TMA sécurité WordPress

Désactiver XML-RPC est un ticket d'une heure, pas un projet. Il vient avec : comptes admin revus, 2FA, limiteur de login, URL d'admin, mises à jour, surveillance des échecs de connexion. Seul, il aide. Isolé et oublié, il ne sauve pas un mot de passe admin égal à « Bienvenue2026 ».

Si vous voulez une passe de durcissement, je le fais dans cet ordre : inventaire des comptes, 2FA, XML-RPC, URL d'admin, préprod, puis seulement les plugins de scan. L'ordre inverse remplit la boîte mail et laisse la porte ouverte.

🔎 Mesurer l'effet sur la charge

Avant / après, on regarde les hits sur xmlrpc.php, la CPU, les échecs de connexion. Sur un petit mutualisé attaqué, la différence se voit le soir même. On le note dans le journal de TMA. Ça justifie le geste auprès d'un client qui avait peur de « casser l'app ».

Si la charge ne baisse pas, l'attaque est ailleurs (wp-login, REST, un formulaire). On ne s'arrête pas à XML-RPC. On enchaîne 2FA et URL d'admin. Le durcissement est une série, pas un geste isolé.

🛠️ Retour d'expérience : ce qui casse vraiment

Dans les reprises que je fais, ce qui casse après coupure, c'est rarement le rédacteur dans Gutenberg. C'est une vieille app mobile, un Jetpack mal compris, un script de publication d'un ancien prestataire. D'où la liste de contrôle et la préprod. Cinq minutes de questions évitent un lundi de « on ne peut plus publier ».

Désactiver XML-RPC sur WordPress reste, malgré tout, l'un des gestes de sécurité les plus rentables. Il n'est pas exotique. Il est juste oublié, parce qu'il n'y a pas de pastille verte à montrer. La pastille, c'est le access.log plus calme.

XML-RPC ouvert, c'est une porte que plus personne n'utilise, sauf les bots.