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 chevronné 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 :

• Publication de contenu à distance — Les clients de blog comme Windows Live Writer ou MarsEdit pouvaient publier des articles directement sur votre site.
• Gestion d’applications mobiles — L’application mobile WordPress officielle dépendait historiquement de XML-RPC pour gérer les articles, les pages et les commentaires.
• Rétroliens et pingbacks — Le protocole gère les notifications entre sites, alertant les autres blogs lorsque vous établissez un lien vers leur contenu.
• Intégrations tierces — Des services comme IFTTT, Zapier (dans les configurations plus anciennes) et divers plugins utilisaient XML-RPC pour interagir avec WordPress par programmation.

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 objectifs. En conséquence, xmlrpc.php est maintenant 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 lorsque 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 largement exploitée. Les attaques par force brute standard contre la page de connexion WordPress (wp-login.php) sont limitées à une tentative d’authentification 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 :

• Les plugins traditionnels de limitation de débit et de 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 pingbacks

Les attaquants peuvent exploiter la fonctionnalité de pingback 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 pingback spécialement conçue, un acteur malveillant peut instruire votre serveur d’envoyer des requêtes HTTP à une URL cible — utilisant effectivement les ressources et la réputation IP de votre serveur 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 de balayage automatisés qui sondent les vulnérabilités. Ces sondes constantes consomment des cycles CPU, de la mémoire et de la bande passante — des ressources qui devraient servir vos visiteurs légitimes. Particulièrement dans les environnements d’hébergement partagé, cela peut dégrader notablement les performances du site.

4. Exposition inutile

Si vous n’utilisez pas d’outils de publication à distance, d’applications mobiles nécessitant XML-RPC ou d’intégrations tierces héritées, alors xmlrpc.php offre zéro avantage à 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 réellement 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 à celle 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.

Étape par étape :

1. Connectez-vous à votre tableau de bord d’administration WordPress.
2. Accédez à Extensions → Ajouter une extension.
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 Ajustements WordPress.
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.

Étape par étape :

1. Accédez aux fichiers de votre site via FTP (en utilisant FileZilla ou similaire) ou via le Gestionnaire de fichiers du panneau de contrôle de votre hébergement.
2. Accédez au répertoire racine de votre 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 édition et ajoutez le bloc suivant à la fin du fichier :

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

1. Enregistrez le fichier et fermez votre éditeur.

Pour vérifier que cela fonctionne, visitez votresite.com/xmlrpc.php dans votre navigateur. Vous devriez recevoir une erreur 403 Interdit 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 .htaccess incorrectes 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 :

>

> location = /xmlrpc.php {
> deny all;
> }

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

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

Étape par étape :

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 :

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 de thème), créez un simple plugin personnalisé :

1. En utilisant FTP ou le Gestionnaire de fichiers, accédez à 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: Désactive la fonctionnalité XML-RPC
Version: 1.0
*/
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 à inverser.

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 (crochet de filtre) :

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

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 votresite.com/xmlrpc.php. Un blocage réussi affiche une erreur 403 Interdit ou 404 Non trouvé.
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 requête restante vers 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 sécurité WordPress. La base d’un site WordPress sécurisé commence par choisir le bon fournisseur d’hébergement — un 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 dans la pile d’hébergement. Que vous exécutiez 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 d’implémenter 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 rentable 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 transmis 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 du registraire tiers.

L’association d’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 cassera-t-elle mon site WordPress ?

Pour la plupart des utilisateurs, non. Si vous n’utilisez pas de clients de blog de bureau hérités, l’application WordPress officielle (les versions modernes utilisent l’API REST) 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 versions plus anciennes de Jetpack dépendaient de XML-RPC. Les versions modernes de Jetpack utilisent principalement l’API REST de 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 garder XML-RPC actif à d’autres fins mais éliminer les abus de pingback, ajoutez ceci à votre functions.php :

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.