Qu’est-ce que xmlrpc.php dans WordPress et comment le désactiver (Guide complet 2024)

WordPress alimente plus de 43% de tous les sites web sur Internet — et cette domination s’accompagne d’une surface d’attaque importante. L’un des points d’entrée les plus fréquemment exploités est un fichier appelé xmlrpc.php. Que vous soyez un développeur expérimenté ou un propriétaire de site gérant votre première installation WordPress, comprendre ce que fait ce fichier, pourquoi il est dangereux et comment le désactiver est essentiel pour sécuriser votre site.

Ce guide couvre tout ce que vous devez savoir sur xmlrpc.php : son objectif, les menaces réelles qu’il introduit, et trois méthodes éprouvées pour le désactiver — aucun diplôme technique requis.

Qu’est-ce que xmlrpc.php dans WordPress ?

xmlrpc.php est un fichier WordPress principal qui implémente le protocole XML-RPC — un système d’appel de procédure distante (RPC) qui utilise XML pour encoder les appels et HTTP comme mécanisme de transport. En termes simples, il permet aux applications et services externes de communiquer avec votre site WordPress sans utiliser l’interface standard du navigateur web.

Introduit bien avant l’existence de l’API REST WordPress, xmlrpc.php était le pont principal entre WordPress et le monde extérieur. Il permettait :

• La publication de contenu à distance — Les clients de blog comme Windows Live Writer ou MarsEdit pouvaient publier des articles directement sur votre site.
• La gestion d’applications mobiles — L’application mobile officielle WordPress s’appuyait historiquement sur XML-RPC pour gérer les articles, les pages et les commentaires.
• Les rétroliens et les pingbacks — Le protocole gère les notifications inter-sites, alertant les autres blogs lorsque vous créez un lien vers leur contenu.
• Les intégrations tierces — Des services comme IFTTT, Zapier (dans les anciennes configurations) et diverses extensions utilisaient XML-RPC pour interagir avec WordPress de manière programmatique.

Bien que ces fonctionnalités aient été véritablement utiles au début des années 2010, WordPress a depuis introduit l’API REST, qui offre un moyen plus sécurisé, moderne et flexible d’atteindre les mêmes résultats. Par conséquent, xmlrpc.php est désormais largement obsolète — mais il reste actif par défaut sur chaque installation WordPress.

Pourquoi xmlrpc.php est-il un risque de sécurité ?

Le problème avec xmlrpc.php n'est pas le protocole lui-même — c'est que le fichier reste activé même quand vous ne l'utilisez pas, créant un vecteur d'attaque inutile. Les chercheurs en sécurité et les fournisseurs d'hébergement le signalent régulièrement comme l'une des principales vulnérabilités WordPress. Voici pourquoi :

1. Attaques d'amplification par force brute

C'est la menace la plus dangereuse et la plus exploitée. Les attaques par force brute standard contre la page de connexion WordPress (wp-login.php) sont limitées à une tentative d'identification par requête HTTP. XML-RPC change cela de manière spectaculaire.

La méthode system.multicall dans XML-RPC permet à un attaquant de regrouper des centaines ou même des milliers de combinaisons nom d'utilisateur/mot de passe dans une seule requête HTTP. Cela signifie :

• La limitation de débit traditionnelle et les plugins de limitation des tentatives de connexion sont contournés.
• Les attaquants peuvent tester d'énormes listes d'identifiants avec une bande passante minimale.
• Les journaux du serveur affichent beaucoup moins de requêtes, ce qui rend la détection plus difficile.

Un seul botnet peut compromettre un site WordPress avec un mot de passe faible en quelques minutes en utilisant cette technique.

2. Amplification DDoS via les rétroliens

Les attaquants peuvent exploiter la fonctionnalité de rétrolien dans xmlrpc.php pour transformer votre site WordPress en participant involontaire à une attaque par déni de service distribué (DDoS). En envoyant une requête de rétrolien spécialement conçue, un acteur malveillant peut instruire votre serveur d'envoyer des requêtes HTTP vers une URL cible — utilisant effectivement les ressources de votre serveur et votre réputation IP contre un tiers.

Cela non seulement nuit à la cible de l'attaque, mais peut également faire que l'IP de votre serveur soit mise sur liste noire, affectant la délivrabilité et la réputation de votre site.

3. Épuisement des ressources du serveur

Même sans une attaque coordonnée, xmlrpc.php est une cible courante pour les bots d'analyse automatisée qui sondent les vulnérabilités. Ces sondages constants consomment des cycles CPU, de la mémoire et de la bande passante — des ressources qui devraient servir vos visiteurs légitimes. Sur les environnements d'hébergement partagé en particulier, cela peut dégrader notablement les performances du site.

4. Exposition inutile

Si vous n'utilisez pas les outils de publication à distance, les applications mobiles qui nécessitent XML-RPC, ou les intégrations tierces héritées, alors xmlrpc.php ne fournit aucun bénéfice à votre site tout en maintenant une surface d'attaque entièrement active. Le principe du moindre privilège en sécurité stipule : si vous n'en avez pas besoin, désactivez-le.

Avez-vous vraiment besoin de xmlrpc.php ?

Avant de le désactiver, posez-vous la question :

Pour la grande majorité des propriétaires de sites WordPress, la réponse est : vous n’en avez pas besoin. Désactivez-le.

Comment désactiver xmlrpc.php dans WordPress : 3 méthodes

Il existe trois méthodes fiables pour désactiver xmlrpc.php, allant de la plus conviviale pour les débutants au niveau du serveur. Choisissez celle qui correspond le mieux à votre niveau de confort technique et à votre environnement d’hébergement.

Méthode 1 : Utiliser un plugin de sécurité WordPress (La plus facile)

Si vous voulez une solution sans code avec un risque minimal de casser quelque chose, un plugin de sécurité est votre meilleur point de départ.

Plugins recommandés :

• Wordfence Security — Pare-feu complet et scanner de malware avec blocage XML-RPC.
• iThemes Security (maintenant Solid Security) — Bouton dédié pour désactiver XML-RPC.
• Disable XML-RPC — Un plugin léger à usage unique qui fait exactement ce qu’il dit.

Étapes :

1. Connectez-vous à votre tableau de bord WordPress.
2. Allez à Extensions → Ajouter.
3. Recherchez votre plugin choisi (par exemple, « Disable XML-RPC ») et cliquez sur Installer maintenant, puis Activer.
4. Allez à la page des paramètres du plugin. Pour les plugins de sécurité dédiés comme Wordfence ou iThemes Security, recherchez une section intitulée XML-RPC ou WordPress Tweaks.
5. Activez l’option pour désactiver XML-RPC ou bloquer les requêtes XML-RPC.
6. Enregistrez vos modifications.

Avantages : Simple, réversible, aucune édition de fichier requise.

Inconvénients : Ajoute une dépendance de plugin ; le fichier existe toujours sur le serveur (les requêtes sont bloquées au niveau de l’application, pas au niveau du serveur).

Méthode 2 : Bloquer xmlrpc.php via .htaccess (Recommandé pour les serveurs Apache)

Pour les environnements d’hébergement basés sur Apache, l’édition du fichier .htaccess bloque les requêtes au niveau du serveur web — avant même que WordPress ne se charge. C’est plus efficace et offre une protection plus forte qu’un plugin seul.

Étapes :

1. Accédez aux fichiers de votre site via FTP (en utilisant FileZilla ou similaire) ou via le Gestionnaire de fichiers de votre panneau de contrôle d’hébergement.
2. Naviguez vers votre répertoire racine WordPress — c’est généralement public_html ou www.
3. Localisez le fichier .htaccess. Si vous ne le voyez pas, activez les fichiers cachés dans votre client FTP (dans FileZilla : Serveur → Forcer l’affichage des fichiers cachés) ou dans les paramètres de votre gestionnaire de fichiers.
4. Ouvrez .htaccess pour l’édition et ajoutez le bloc suivant à la fin du fichier :

# Block WordPress xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

1. Enregistrez le fichier et fermez votre éditeur.

Pour vérifier que cela fonctionne, visitez https://yourdomain.com/xmlrpc.php dans votre navigateur. Vous devriez recevoir une erreur 403 Forbidden au lieu de la réponse XML-RPC par défaut.

Avantages : Le blocage au niveau du serveur est plus efficace ; réduit la charge du serveur ; aucun plugin requis.

Inconvénients : Nécessite un accès aux fichiers ; les éditions incorrectes de .htaccess peuvent temporairement casser votre site (gardez toujours une sauvegarde).

> Conseil professionnel : Si votre hébergement utilise Nginx au lieu d’Apache, ajoutez plutôt ce qui suit à la configuration de votre bloc serveur Nginx :

>

> “`nginx

> location = /xmlrpc.php {

> deny all;

> access_log off;

> log_not_found off;

> }

> “`

Méthode 3 : Désactiver via functions.php (Crochet de filtre WordPress)

Cette méthode utilise un filtre WordPress pour désactiver programmatiquement la fonctionnalité XML-RPC depuis le thème ou un plugin personnalisé. C’est une solution propre et basée sur le code qui fonctionne au niveau de la couche application WordPress.

Étapes :

Option A — Via l’éditeur de thème (rapide mais non recommandé pour la production) :

1. Dans votre tableau de bord WordPress, allez à Apparence → Éditeur de thème.
2. Sélectionnez functions.php dans la liste des fichiers sur le côté droit.
3. Ajoutez le code suivant à la fin du fichier :

// Disable XML-RPC
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Cliquez sur Mettre à jour le fichier pour enregistrer.

Option B — Via un plugin personnalisé (recommandé) :

Plutôt que d’éditer le functions.php de votre thème (qui est écrasé lors des mises à jour du thème), créez un simple plugin personnalisé :

1. En utilisant FTP ou le Gestionnaire de fichiers, naviguez vers wp-content/plugins/.
2. Créez un nouveau dossier appelé disable-xmlrpc.
3. À l’intérieur de ce dossier, créez un fichier appelé disable-xmlrpc.php avec le contenu suivant :

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Disables XML-RPC functionality for improved security.
 * Version: 1.0
 * Author: Your Name
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

1. Allez à Extensions → Extensions installées dans votre tableau de bord et activez Disable XML-RPC.

Avantages : Propre, indépendant du thème (lors de l’utilisation de la méthode du plugin personnalisé) ; facile à annuler.

Inconvénients : Niveau application uniquement — le fichier existe toujours et peut recevoir des requêtes (bien qu’elles seront rejetées) ; ne réduit pas la charge du serveur aussi efficacement que le blocage .htaccess.

Combiner les méthodes pour une sécurité maximale

Pour la protection la plus forte, combinez la méthode 2 (.htaccess) avec la méthode 3 (filtre hook) :

• La règle .htaccess bloque les demandes au niveau du serveur, réduisant la charge.
• Le filtre hook garantit que XML-RPC est désactivé même si la règle .htaccess est jamais contournée ou réécrite.

Cette approche en couches suit le principe de sécurité de la défense en profondeur — plusieurs contrôles indépendants protégeant le même actif.

Comment vérifier que xmlrpc.php est désactivé avec succès

Après avoir appliqué votre méthode choisie, confirmez que cela fonctionne :

1. Test du navigateur : Visitez https://yourdomain.com/xmlrpc.php. Un blocage réussi affiche une erreur 403 Forbidden ou 404 Not Found.
2. Vérificateur XML-RPC en ligne : Utilisez un outil comme xmlrpc.eritreo.it pour tester si le point de terminaison XML-RPC de votre site répond.
3. Journaux du serveur : Vérifiez vos journaux d’accès pour toute demande restante à xmlrpc.php — une baisse soudaine confirme que le blocage fonctionne.

Choisir le bon hébergement pour la sécurité WordPress

Désactiver xmlrpc.php n’est qu’une couche de la sécurité WordPress. La base d’un site WordPress sécurisé commence par choisir le bon fournisseur d’hébergement — celui qui offre des contrôles de sécurité au niveau du serveur, des sauvegardes régulières et une infrastructure conçue pour résister aux attaques.

Chez AlexHost, la sécurité WordPress est intégrée à la pile d’hébergement. Que vous gériez un blog personnel ou un site commercial à fort trafic, le bon plan fait une différence significative :

• Hébergement VPS — L’accès root complet vous permet de mettre en œuvre des configurations de sécurité au niveau du serveur, y compris des règles Nginx ou Apache personnalisées pour bloquer xmlrpc.php au niveau de l’infrastructure. Idéal pour les développeurs et les sites en croissance qui ont besoin d’un contrôle granulaire.

• Hébergement Web Partagé — Un point d’entrée économique pour les sites WordPress, avec des configurations de sécurité gérées et un accès facile à l’édition .htaccess via le panneau de contrôle.

• VPS avec cPanel — Combine la puissance d’un serveur privé virtuel avec l’interface cPanel familière, ce qui facilite la gestion des fichiers .htaccess, des certificats SSL et des paramètres de sécurité sans expertise en ligne de commande.

• Certificats SSL — Chiffrer votre site avec HTTPS est une base de sécurité non négociable. Un certificat SSL garantit que même si des requêtes XML-RPC sont effectuées, les identifiants et les données transmises sont chiffrés en transit.

• Enregistrement de Domaine — Gardez votre domaine et votre hébergement sous un même toit pour une gestion DNS simplifiée et une surface d’attaque réduite des vulnérabilités des bureaux d’enregistrement tiers.

Associer une infrastructure d’hébergement solide avec un durcissement au niveau de l’application comme la désactivation de xmlrpc.php donne à votre site WordPress une posture de sécurité robuste et multicouche.

Questions fréquemment posées

La désactivation de xmlrpc.php va-t-elle casser mon site WordPress ?

Pour la plupart des utilisateurs, non. Si vous n’utilisez pas de clients de blogage de bureau hérités, l’application WordPress officielle (les versions modernes utilisent REST API), ou des intégrations tierces spécifiques qui nécessitent explicitement XML-RPC, la désactivation n’aura aucun effet notable sur la fonctionnalité.

Jetpack nécessite-t-il xmlrpc.php ?

Les anciennes versions de Jetpack s’appuyaient sur XML-RPC. Les versions modernes de Jetpack utilisent principalement l’API REST WordPress.com. Consultez la documentation de votre version spécifique de Jetpack avant de désactiver XML-RPC.

Puis-je simplement désactiver les pingbacks au lieu de tout XML-RPC ?

Oui. Si vous souhaitez conserver XML-RPC actif à d’autres fins mais éliminer les abus de pingback, ajoutez ceci à votre functions.php :

// Disable pingbacks only
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

xmlrpc.php est-il supprimé dans les versions plus récentes de WordPress ?

Non. À partir des dernières versions de WordPress, xmlrpc.php est toujours inclus et activé par défaut. L’équipe principale de WordPress a discuté de son avenir, mais il reste présent pour la compatibilité rétroactive.

Conclusion

xmlrpc.php est un fichier WordPress hérité qui a autrefois servi un objectif légitime mais représente aujourd’hui l’une des vulnérabilités les plus couramment exploitées dans les installations WordPress dans le monde entier. À moins que vous ayez un besoin spécifique et documenté pour la fonctionnalité XML-RPC, la désactiver est une amélioration de sécurité simple et à fort impact qui prend moins de cinq minutes à mettre en œuvre.

Pour récapituler vos options :

Appliquez la méthode qui convient à votre environnement, vérifiez que le blocage fonctionne, et combinez-le avec une base d’hébergement solide. La sécurité n’est pas une action unique — c’est une pratique continue. Maintenez votre WordPress core, vos thèmes et vos plugins à jour, surveillez régulièrement vos journaux d’accès, et choisissez une infrastructure d’hébergement qui soutient vos objectifs de sécurité dès le départ.