Désactiver XML-RPC sur WordPress : La méthode la plus rapide contre les attaques brute force

La désactivation de XML-RPC sur WordPress consiste à bloquer le fichier xmlrpc.php contre les requêtes distantes, réduisant ainsi rapidement les tentatives de brute force, les abus de pingback et le trafic inutile des bots. Si vous n’utilisez pas Jetpack, l’application mobile WordPress, des outils de publication distants anciens ou une intégration spécifique nécessitant XML-RPC, couper XML-RPC est un geste sécurisant et efficace pour la plupart des sites WordPress. La méthode la plus performante consiste à bloquer l’accès au niveau serveur, avant même que WordPress ne soit chargé : c’est-à-dire via une règle Apache, LiteSpeed, Nginx ou pare-feu applicatif (WAF). Cette approche est généralement plus rapide qu’une simple désactivation via plugin.

Dans ce guide, vous découvrirez pourquoi désactiver XML-RPC, dans quels cas il ne faut pas le faire et comment appliquer ce réglage de façon fiable, selon votre environnement d’hébergement. Que vous soyez sur Hostragons ou un autre hébergeur, l’objectif est de sécuriser votre site sans l’endommager, de réduire la consommation de ressources et d’établir une base de sécurité gérable. Pour un hébergement WordPress rapide et sécurisé, le choix de Hébergement WordPress fait aussi partie intégrante de cette démarche.

XML-RPC : qu’est-ce que c’est et à quoi sert-il sur WordPress ?

XML-RPC est un vieux protocole de communication permettant à différents systèmes d’échanger des données en XML via HTTP. Sur WordPress, cela passe par le fichier xmlrpc.php à la racine du site. Historiquement, ce fichier servait à publier des articles depuis l’application mobile, gérer les commentaires à distance, activer les pingbacks et permettre à certains services tiers d’interagir avec le site.

Avec l’essor de l’API REST, XML-RPC est devenu largement obsolète sur les installations modernes. Toutefois, le fichier reste accessible sur beaucoup de sites, ce qui en fait une cible facile, connue et automatisable pour les attaquants. Les bots qui scannent des plages d’IP ou de domaines testent systématiquement xmlrpc.php, parfois même quelques minutes après la mise en ligne d’un nouveau site. Il est donc crucial, lors de l’activation d’un nom de domaine via Vérification de domaine, de penser à la sécurité dès le départ.

Dans quels cas XML-RPC reste-t-il nécessaire ?

XML-RPC n’est pas indispensable pour tous les sites. Certaines anciennes fonctionnalités de Jetpack, l’application mobile WordPress, des outils d’automation ou des éditeurs de blog “desktop” peuvent encore en avoir besoin. Des intégrations sur mesure peuvent également s’appuyer sur xmlrpc.php pour l’envoi de contenu ou la récupération de données. Avant de le désactiver, vérifiez donc le flux de travail de votre site.

Le test pratique : si vous saisissez vos contenus uniquement via le tableau de bord wp-admin, si vous n’utilisez pas Jetpack, si vous ne publiez pas depuis l’application mobile et que votre développeur n’a pas mis en place d’intégration XML-RPC personnalisée, il y a de fortes chances que vous puissiez couper XML-RPC sans aucun impact. Sites vitrine, blogs, catalogues, petits sites d’entreprise et boutiques WooCommerce fonctionnent généralement très bien sans XML-RPC. Pour les processus critiques comme le paiement ou la logistique, testez le changement pendant les heures creuses.

Pourquoi XML-RPC est-il un risque de brute force sur WordPress ?

Une attaque brute force consiste à tester automatiquement des milliers de combinaisons d’identifiants et mots de passe. Sur WordPress, cela se fait souvent via wp-login.php, mais XML-RPC offre une porte d’entrée encore plus avantageuse. En effet, certains appels XML-RPC permettent d’effectuer plusieurs tentatives dans une seule requête HTTP, notamment via la méthode system.multicall. Sur un système mal configuré, cela permet d’envoyer des centaines de tentatives “en lot”, beaucoup plus discrètement.

Par exemple, 500 essais via wp-login.php représentent 500 requêtes distinctes, alors qu’en XML-RPC, ils peuvent être regroupés en quelques requêtes. Les plugins de sécurité et les logs peuvent alors détecter l’attaque plus tardivement. Cela entraîne une hausse de l’utilisation CPU, occupe les workers PHP, surcharge la base de données et ralentit l’expérience pour les vrais visiteurs. Sur un hébergement mutualisé, c’est autant un problème de sécurité que de performance.

XML-RPC pose aussi problème avec le pingback, une fonctionnalité conçue pour signaler les liens entrants. Mal utilisé, le pingback peut générer un trafic de type DDoS ou servir à pointer d’autres sites comme cibles. Désactiver XML-RPC permet donc non seulement de limiter les tentatives de connexion, mais aussi les abus de pingback.

Comparatif rapide des méthodes de désactivation XML-RPC

Comme le montre le tableau, la méthode la plus rapide et robuste est le blocage au niveau serveur ou WAF si XML-RPC n’est pas nécessaire. Un plugin est facile à utiliser, mais la requête consomme toujours des ressources si elle atteint PHP. Pour les sites à fort trafic, e-commerce ou régulièrement attaqués, privilégiez la règle serveur en priorité.

Checklist avant de commencer

En sécurité, la règle d’or est de mesurer et prévoir un plan de retour arrière. Désactiver XML-RPC est la plupart du temps sans risque, mais aucune modification ne doit être faite à l’aveugle sur un site en production. Voici une liste pour limiter les erreurs pendant l’opération :

• Ayez une sauvegarde fonctionnelle du site et de la base datant de moins de 24h. Avant tout changement de sécurité, plugin ou mise à jour WordPress, la sauvegarde est obligatoire.
• Vérifiez si Jetpack, l’application mobile WordPress, un outil de publication distant ou une intégration personnalisée sont utilisés.
• Examinez le nombre de requêtes xmlrpc.php dans vos logs d’accès. Si vous en voyez des dizaines ou centaines par minute, le site subit probablement une attaque.
• Effectuez le changement lors des heures creuses. Sur une boutique WooCommerce, testez ensuite le panier, le paiement et les inscriptions.
• Préparez une méthode de retour arrière : accès FTP, SSH ou gestionnaire de fichiers pour commenter ou supprimer la règle ajoutée.

Un hébergement professionnel se distingue par des sauvegardes régulières, une version PHP à jour, des comptes isolés et un pare-feu efficace. Pour choisir votre infrastructure, consultez Hébergement Web Sécurisé et pour la sécurité globale du site, certificat SSL.

Méthode 1 : Désactiver XML-RPC via .htaccess sur Apache ou LiteSpeed

Sur Apache ou LiteSpeed, la méthode la plus courante est d’ajouter une règle dans le fichier .htaccess à la racine du site pour bloquer l’accès à xmlrpc.php. LiteSpeed étant compatible avec les règles Apache, cette technique fonctionne sur la grande majorité des hébergeurs. Son principal avantage : la requête est rejetée avant même que WordPress ne soit chargé.

Étapes à suivre

• Ouvrez le gestionnaire de fichiers de votre hébergeur ou connectez-vous en FTP au dossier public_html.
• Trouver le fichier .htaccess et en faire une sauvegarde locale. Si le fichier n’apparaît pas, activez l’affichage des fichiers cachés.
• Ajoutez la règle de blocage XML-RPC en haut du fichier, sans effacer les règles générées par WordPress.
• La logique : refuser tous les accès à xmlrpc.php.
• Enregistrez puis testez l’accès à domaine.com/xmlrpc.php dans votre navigateur.

Sur Apache 2.4 et LiteSpeed, la règle consiste à appliquer “Require all denied” sur xmlrpc.php. Sur les anciens Apache 2.2, “Deny from all” était utilisé, mais il est fortement conseillé de migrer vers un serveur à jour d’ici 2026 pour la sécurité globale. Si vous êtes encore sur une vieille version Apache, cela dépasse la question XML-RPC et mérite une mise à niveau urgente.

Avec un blocage réussi, xmlrpc.php renverra un code 403 Forbidden, 404 Not Found ou une réponse similaire selon votre configuration. L’essentiel est d’éviter toute réponse du type “XML-RPC server accepts POST requests”. Si vous voyez cette phrase, le fichier reste accessible.

Méthode 2 : Bloquer XML-RPC sur Nginx

Sur Nginx, .htaccess ne fonctionne pas, car Nginx ne lit pas les fichiers par dossier. Il faut donc ajouter la règle dans le bloc serveur ou vhost du site. Si votre hébergement est géré, vous n’avez pas toujours accès à cette configuration : demandez alors au support technique de bloquer xmlrpc.php pour vous.

La méthode : utiliser un bloc location = /xmlrpc.php pour refuser l’accès ou renvoyer un 404. Un 403 est plus explicite, un 404 donne moins d’indications aux bots. Après ajout, testez la configuration Nginx et rechargez le service. Toute erreur dans le fichier peut rendre le site inaccessible, donc soyez très rigoureux.

Après modification sur un VPS ou serveur dédié, surveillez les logs d’accès : les requêtes xmlrpc.php doivent désormais donner des codes 403 ou 404. Si certains IP continuent leurs tentatives, ajoutez fail2ban, rate limit ou une règle WAF pour une défense en profondeur. Pour un guide de sécurité serveur, voyez sécurité du serveur VPS.

Méthode 3 : Désactivation via plugin de sécurité

Pour les utilisateurs ne souhaitant pas toucher aux fichiers techniques, les plugins de sécurité sont une solution rapide. Wordfence, Solid Security, All-In-One Security et autres proposent de désactiver XML-RPC, de bloquer les pingbacks ou de limiter les tentatives de login via XML-RPC. Cette méthode est idéale pour les blogs ou sites corporate simples.

Mais il faut connaître la limite : si le plugin ne bloque qu’après le chargement de WordPress, la requête consomme toujours des ressources PHP. Sur une attaque massive, CPU et mémoire ne seront pas totalement préservés. Le plugin est donc préférable à aucune protection, mais pour un site sous attaque, combinez-le à une règle serveur ou WAF.

À surveiller avec les plugins

• Téléchargez les plugins de sécurité uniquement depuis le répertoire officiel WordPress ou le site du développeur.
• Évitez les plugins non mis à jour depuis longtemps. En 2026, la maintenance et la compatibilité sont un gage de confiance.
• Ne superposez pas plusieurs plugins ayant la même fonction : cela cause des conflits sur l’accès, le cache et les formulaires.
• Après réglage XML-RPC, testez le tableau de bord, les formulaires, l’inscription et le paiement.
• Consultez régulièrement les logs du plugin. Si les attaques persistent, bloquez les IP ou ajoutez une règle WAF.

Méthode 4 : Blocage via WAF, CDN et pare-feu hébergeur

Un pare-feu applicatif (WAF) filtre les requêtes malveillantes avant qu’elles n’atteignent WordPress. Cloudflare et autres CDN permettent de bloquer xmlrpc.php “devant” le serveur. Votre hébergeur propose peut-être ModSecurity ou des règles WAF personnalisées pour le même usage. Cette couche est idéale pour stopper le flot de bots avant qu’il ne touche WordPress.

La règle WAF doit être claire : si l’URI contient xmlrpc.php, bloquer ou appliquer un challenge. Si XML-RPC n’est pas nécessaire, le blocage doit être total. Si le besoin est partiel, autorisez seulement certains IP. Par exemple, une intégration d’automation venant d’un IP fixe peut être whiteliste, toutes les autres requêtes sont bloquées. C’est un équilibre entre sécurité et continuité de service.

Le WAF fonctionne encore mieux avec SSL. Sans HTTPS, les identifiants et sessions restent vulnérables. Profitez de la désactivation XML-RPC pour passer tout le site en HTTPS, activer HSTS et surveiller la validité du certificat. Pour approfondir, consulter certificat SSL et Installation de SSL gratuit.

Comment tester la désactivation de XML-RPC ?

Après modification, ne vous contentez pas de vérifier que le site s’ouvre. Contrôlez : XML-RPC est-il bien fermé ? Les logins fonctionnent-ils ? Les utilisateurs réels sont-ils impactés ? Les logs montrent-ils le résultat attendu ? Voici un flux de test pratique :

• Ouvrez domaine.com/xmlrpc.php dans votre navigateur. Vous devez obtenir un refus, un code 404 ou une page blanche. Le message “XML-RPC server accepts POST requests” ne doit plus apparaître.
• Connectez-vous à l’administration WordPress avec vos identifiants habituels. La page de login doit fonctionner indépendamment de XML-RPC.
• Testez les formulaires de contact, de commentaire, l’inscription et le paiement WooCommerce.
• Vérifiez dans les logs serveur les codes de réponse aux requêtes xmlrpc.php : 403 ou 404 indique une règle active.
• Si vous utilisez un plugin de sécurité, consultez les journaux : vous devriez voir une baisse des tentatives de bots ou leur blocage.

Pour un test technique, envoyez une requête POST depuis le terminal, mais pour la plupart des utilisateurs, le navigateur et les logs suffisent. Si Jetpack ne se connecte plus, l’application mobile ne publie pas ou une intégration renvoie une erreur, XML-RPC est réellement nécessaire. Dans ce cas, privilégiez le whitelist IP ou le rate limit plutôt qu’un blocage total.

Est-ce suffisant ? Autres mesures essentielles de sécurité WordPress

Désactiver XML-RPC est une étape rapide et efficace contre les brute force, mais n’assure pas à elle seule la sécurité totale. Les attaquants peuvent cibler wp-login.php, l’API REST, des plugins vulnérables, des thèmes obsolètes ou des mots de passe compromis. Il faut penser la sécurité WordPress en plusieurs couches.

Les bonnes pratiques à appliquer

• Utilisez des mots de passe forts et un nom d’utilisateur unique. Ne jamais utiliser “admin” comme identifiant.
• Activez la double authentification (2FA) pour les comptes administrateurs.
• Limitez les tentatives de connexion sur wp-login.php via plugin ou rate limit.
• Gardez WordPress, les plugins et les thèmes à jour. Les plugins non maintenus sont une cause fréquente de failles.
• Supprimez les extensions et thèmes inutilisés. Même inactifs, ils représentent un risque sur le système de fichiers.
• Vérifiez les permissions des fichiers : limitez les droits d’écriture inutiles pour éviter le téléchargement de fichiers malveillants.
• Faites des sauvegardes régulières et testez la restauration. Une sauvegarde non testée n’est qu’une hypothèse.
• Optez pour un hébergement fiable : isolation, PHP à jour, WAF et sauvegardes réduisent l’impact des attaques.

Si vous coupez XML-RPC mais laissez un mot de passe admin du type “123456”, la chaîne de sécurité reste faible. À l’inverse, mot de passe fort, 2FA, mises à jour, WAF et hébergement sécurisé neutralisent la grande majorité des attaques automatisées. C’est aussi crucial pour le SEO : un site vulnérable peut subir du spam, du détournement de trafic ou perdre sa visibilité organique.

Impact de la désactivation XML-RPC sur la performance et le SEO

Les attaques XML-RPC ne sont pas un facteur direct de classement Google, mais leur impact indirect est majeur. Un trafic bot massif consomme les ressources, ralentit le site, dégrade les Core Web Vitals et l’expérience utilisateur. Les sites saturés voient des erreurs 500, des timeout et des coupures. Googlebot peut aussi crawler moins ou plus lentement un site lent ou erroné.

Exemple : votre page d’accueil s’ouvre en 300 ms, mais avec 1000 requêtes/min sur xmlrpc.php, les workers PHP saturent et le temps de réponse dépasse 2 secondes. Les clients trouvent le site lent, le taux de conversion chute, les stats Search Console fluctuent. Couper XML-RPC côté serveur élimine cette charge inutile avant même qu’elle n’atteigne WordPress.

Un site rapide et sécurisé repose autant sur la qualité du contenu que sur l’infrastructure technique : HTTPS, PHP à jour, disques rapides, bon cache, thème optimisé et surface d’attaque réduite. Les réglages WordPress doivent être suivis par les équipes SEO autant que les admins. Sur le blog Hostragons, ce sujet est complété par Optimisation de la vitesse WordPress et liste de contrôle SEO technique.

Alternatives si XML-RPC ne peut pas être totalement coupé

Certains projets ne peuvent pas désactiver XML-RPC complètement : publications mobiles, automatisation corporate, vieilles intégrations. Dans ce cas, il ne s’agit pas de laisser la porte grande ouverte mais de contrôler l’accès. Première option : IP whitelist, XML-RPC accessible seulement depuis les IPs de confiance.

Deuxième option : rate limit, limiter le nombre de requêtes xmlrpc.php par IP dans un intervalle donné. Ce n’est pas aussi radical qu’un blocage total, mais réduit la surface d’attaque. Troisième option : désactiver les méthodes pingback tout en gardant celles nécessaires. Cette solution requiert un paramétrage avancé, à confier au développeur.

Quatrième option : protéger XML-RPC par une couche de sécurité supplémentaire : authentification HTTP, VPN, restriction IP corporate, challenge WAF. Idéalement, les anciennes intégrations devraient migrer vers l’API REST, plus moderne et contrôlable.

Guide pratique pour les utilisateurs Hostragons

Si vous hébergez votre site WordPress chez Hostragons, commencez par analyser vos besoins en XML-RPC, puis choisissez la méthode la plus simple. Sur un hébergement mutualisé ou WordPress, la modification du .htaccess via le gestionnaire de fichiers est suffisante pour la plupart des utilisateurs. Sur un VPS ou serveur dédié, combinez Nginx, Apache, LiteSpeed et WAF selon vos options.

Le déroulé recommandé : sauvegarde d’abord, vérification des services utilisant XML-RPC, blocage au niveau serveur, tests fonctionnels, suivi des logs pendant 24h. Si les attaques persistent, ajoutez une règle WAF, blocage IP et limitation des tentatives de connexion. Enfin, activez 2FA, gardez le site à jour, sauvegardez régulièrement et assurez-vous d’avoir un SSL valide.

Ce n’est pas une “option premium”, mais une mesure d’hygiène de base. Si votre infrastructure présente des failles (version PHP obsolète, ressources limitées, absence de pare-feu), pensez à un hébergement plus moderne. Un environnement optimisé WordPress, avec plusieurs couches de sécurité, améliore à la fois la résistance aux attaques et la performance quotidienne. Pour aller plus loin, lisez Hébergement WordPress, Serveur cloud et certificat SSL.

FAQ : Questions fréquemment posées

La désactivation XML-RPC peut-elle casser mon site WordPress ?

Pour la plupart des sites WordPress standards, désactiver XML-RPC n’a aucun impact sur le fonctionnement du site : administration, thème, contenu, formulaires, côté visiteur restent inchangés. Jetpack, l’application mobile ou une intégration personnalisée peuvent en revanche présenter des problèmes de connexion. Vérifiez donc les usages avant de couper XML-RPC et testez les fonctions principales après.

Comment savoir si XML-RPC est bien désactivé ?

Ouvrez domaine.com/xmlrpc.php dans votre navigateur. Si vous voyez “XML-RPC server accepts POST requests”, le fichier est accessible. Si vous obtenez un code 403, 404 ou un refus d’accès, la règle fonctionne. Pour un contrôle précis, examinez les logs serveur : vérifiez le code de réponse aux requêtes xmlrpc.php.

La désactivation de XML-RPC arrête-t-elle définitivement les attaques brute force ?

Elle bloque la grande majorité des tentatives de brute force via XML-RPC, mais ne supprime pas le risque global. Les attaquants peuvent toujours cibler wp-login.php. Combinez donc ce blocage avec des mots de passe forts, 2FA, limitation des tentatives, WAF et une politique de plugins à jour.

Que faire si j’utilise Jetpack ?

Certaines fonctionnalités Jetpack nécessitent XML-RPC. Avant de désactiver, vérifiez quels modules sont utilisés. Alternativement, autorisez uniquement les IPs des services Jetpack ou appliquez un contrôle d’accès via WAF.

Plugin ou règle serveur : quelle méthode choisir ?

Pour la meilleure performance et sécurité, privilégiez les règles serveur ou WAF : la requête est refusée avant le chargement de WordPress. Le plugin est plus simple pour les utilisateurs non techniques, mais n’empêche pas totalement la consommation de ressources en cas d’attaque. Si possible, choisissez la règle serveur ; sinon, un plugin fiable et un WAF.

Résumé et prochaines étapes

Désactiver XML-RPC sur WordPress est l’une des méthodes les plus rapides pour réduire brute force, abus de pingback et trafic bot sur les sites qui n’en ont pas besoin. La meilleure approche : bloquer xmlrpc.php au niveau serveur ou WAF, puis renforcer la sécurité avec des mots de passe forts, 2FA, mises à jour, SSL et sauvegardes régulières. Si vous souhaitez un hébergement WordPress sécurisé, explorez les solutions Hostragons ; pour votre site actuel, un petit checklist suffit pour faire le premier pas dès aujourd’hui.