Comment désactiver XML-RPC dans WordPress

XML-RPC est un protocole d'appel de procédure à distance pris en charge par WordPress depuis ses débuts. Le fichier xmlrpc.php se trouve dans le répertoire racine de votre WordPress et fournit une API permettant à des applications externes de communiquer avec votre site. Bien que cela ait été véritablement utile en 2008 lorsqu'il n'y avait pas de meilleures alternatives, l'API REST (introduite dans WordPress 4.7, en décembre 2016) l'a complètement remplacé pour les cas d'usage légitimes. Aujourd'hui, XML-RPC est principalement exploité par les attaquants pour des tentatives de connexion par force brute et des attaques d'amplification DDoS. Si vous n'utilisez pas Jetpack ou un ancien outil de publication mobile, vous devriez le désactiver.

L'histoire de XML-RPC dans WordPress

Le support de XML-RPC fait partie de WordPress depuis la version 1.5 (2005), mais il était désactivé par défaut. Les propriétaires de sites devaient l'activer manuellement dans les paramètres s'ils voulaient utiliser des clients de blog de bureau comme Windows Live Writer ou MarsEdit. Dans WordPress 3.5 (décembre 2012), l'interface XML-RPC a été activée par défaut et l'option pour la désactiver via l'interface d'administration a été supprimée. Le raisonnement était que les applications mobiles et les services externes s'y appuyaient de plus en plus. Cependant, cette décision signifiait également que chaque installation WordPress avait désormais un point d'accès API ouvert que les attaquants pouvaient cibler.

Avec WordPress 4.7 (décembre 2016), l'API REST est devenue partie intégrante du cœur de WordPress. L'API REST offre une interface moderne basée sur JSON qui est plus flexible, mieux documentée et plus facile à sécuriser que XML-RPC. L'application mobile WordPress est passée de XML-RPC à l'API REST en 2019. À ce stade, le seul service majeur nécessitant encore XML-RPC était Jetpack, et même Jetpack a réduit sa dépendance à XML-RPC au fil du temps.

Comment fonctionne l'attaque par force brute system.multicall

L'aspect le plus dangereux de XML-RPC est la méthode system.multicall. Les attaques par force brute classiques contre la page de connexion WordPress essaient une combinaison nom d'utilisateur/mot de passe par requête HTTP. La limitation de débit et les extensions comme Limit Login Attempts peuvent bloquer efficacement ces attaques car chaque tentative génère une requête séparée.

Le system.multicall de XML-RPC change complètement la donne. Un attaquant peut regrouper des centaines voire des milliers de tentatives d'authentification wp.getUsersBlogs dans une seule requête HTTP. Du point de vue du serveur, cela ressemble à une seule requête. Du point de vue de l'attaquant, il vient de tester 500 mots de passe. Les extensions de limitation de connexions qui fonctionnent au niveau de l'application n'attrapent souvent pas ces tentatives car elles ne voient qu'une seule requête entrante.

Voici à quoi ressemble une charge utile de force brute multicall :

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value><array><data>
        <value><struct>
          <member>
            <name>methodName</name>
            <value><string>wp.getUsersBlogs</string></value>
          </member>
          <member>
            <name>params</name>
            <value><array><data>
              <value><string>admin</string></value>
              <value><string>password123</string></value>
            </data></array></value>
          </member>
        </struct></value>
        <!-- des centaines d'autres tentatives suivent -->
      </data></array></value>
    </param>
  </params>
</methodCall>

Amplification DDoS via les pingbacks

Le deuxième vecteur d'attaque majeur est la fonctionnalité de pingback de XML-RPC. Les pingbacks sont des notifications envoyées entre sites WordPress lorsqu'un site fait un lien vers un autre. Les attaquants en abusent en envoyant des requêtes de pingback falsifiées à des milliers de sites WordPress, toutes pointant vers une URL cible unique. Chaque site WordPress envoie alors une requête de vérification à la cible, transformant ainsi des milliers d'installations WordPress en un botnet de déni de service distribué (DDoS). Le serveur cible est submergé de requêtes entrantes provenant de sites WordPress légitimes, ce qui rend le blocage difficile.

Comment tester si XML-RPC est actuellement activé

Avant d'apporter des modifications, vérifiez si XML-RPC est actif sur votre site. Vous pouvez utiliser curl en ligne de commande :

curl -X POST https://yoursite.com/xmlrpc.php
  -H "Content-Type: text/xml"
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Si XML-RPC est activé, vous recevrez une réponse XML listant toutes les méthodes disponibles (généralement plus de 80 méthodes). S'il est désactivé ou bloqué, vous obtiendrez une erreur 403 Forbidden, une erreur de connexion refusée, ou un message « XML-RPC server accepts POST requests only » (selon la façon dont il a été désactivé).

Vérifier les journaux du serveur pour les attaques XML-RPC

Avant de désactiver XML-RPC, il vaut la peine de vérifier vos journaux d'accès pour voir si vous êtes déjà ciblé. Recherchez les requêtes POST vers xmlrpc.php :

# Journal d'accès Apache
grep "xmlrpc.php" /var/log/apache2/access.log | tail -50

# Journal d'accès Nginx
grep "xmlrpc.php" /var/log/nginx/access.log | tail -50

# Compter les requêtes par IP
grep "xmlrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Si vous voyez des centaines ou des milliers de requêtes POST vers xmlrpc.php depuis diverses adresses IP, votre site est activement ciblé. C'est extrêmement courant, et c'est une raison de plus pour désactiver entièrement le point d'accès.

Méthode 1 : bloquer au niveau du serveur web (recommandé)

Bloquer XML-RPC au niveau du serveur web est l'approche la plus efficace car la requête est rejetée avant même le chargement de PHP. Cela économise des ressources serveur et c'est l'approche que vous devriez préférer au filtrage au niveau PHP.

Apache (.htaccess)

Ajoutez ceci à votre fichier .htaccess dans le répertoire racine de WordPress :

# Bloquer tout accès à xmlrpc.php
<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

Si vous devez autoriser des adresses IP spécifiques (par exemple, si vous utilisez Jetpack), vous pouvez ajouter des exceptions :

<Files xmlrpc.php>
    Order deny,allow
    Deny from all
    Allow from 122.248.245.244
    Allow from 54.217.201.243
</Files>

Nginx

Ajoutez ceci à l'intérieur de votre bloc server dans la configuration Nginx :

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

Les directives access_log off et log_not_found off empêchent vos fichiers journaux de se remplir avec des tentatives XML-RPC bloquées, qui peuvent atteindre plusieurs gigaoctets sur les sites fortement ciblés.

Méthode 2 : désactiver via un filtre WordPress (niveau PHP)

Si vous ne pouvez pas modifier les fichiers de configuration du serveur (courant en hébergement mutualisé), vous pouvez désactiver XML-RPC au niveau PHP. Ajoutez ceci au functions.php de votre thème ou, mieux encore, à une extension must-use personnalisée :

// Désactiver entièrement XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

// Supprimer le lien de découverte XML-RPC de l'en-tête HTML
remove_action('wp_head', 'rsd_link');

// Supprimer l'en-tête HTTP X-Pingback
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Important : le filtre xmlrpc_enabled ne désactive que les méthodes XML-RPC basées sur l'authentification. Le fichier xmlrpc.php se charge toujours, PHP s'exécute toujours, et les méthodes non authentifiées (comme les pingbacks) peuvent toujours fonctionner. C'est pourquoi le blocage au niveau du serveur est préférable. L'approche par filtre consomme tout de même des ressources serveur pour traiter la requête avant de la rejeter.

Créer une extension must-use (recommandé plutôt que functions.php)

Au lieu d'ajouter du code à functions.php (qui est écrasé lors des mises à jour de thème), créez une extension must-use. Créez le fichier wp-content/mu-plugins/disable-xmlrpc.php :

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Désactive complètement la fonctionnalité XML-RPC
 */
add_filter('xmlrpc_enabled', '__return_false');
remove_action('wp_head', 'rsd_link');
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Les extensions must-use se chargent avant les extensions normales et ne peuvent pas être désactivées accidentellement via l'interface d'administration.

Méthode 3 : configuration d'une extension de sécurité

Si vous utilisez une extension de sécurité comme Wordfence, Sucuri ou iThemes Security, elles offrent des options intégrées pour désactiver XML-RPC :

Wordfence : allez dans Wordfence > All Options > Brute Force Protection. Le pare-feu limite automatiquement le débit des tentatives d'authentification XML-RPC. Pour un blocage complet, utilisez la méthode au niveau du serveur ci-dessus.
iThemes Security : allez dans Security > Settings > WordPress Tweaks. Activez « Disable XML-RPC » pour le bloquer complètement, ou sélectionnez « Disable Pingbacks » pour ne bloquer que le vecteur d'abus des pingbacks tout en gardant les autres méthodes XML-RPC fonctionnelles.
Sucuri : le pare-feu d'application web Sucuri (basé sur le cloud) peut bloquer XML-RPC au niveau du CDN avant même que les requêtes n'atteignent votre serveur.

Règles WAF Cloudflare pour la protection XML-RPC

Si vous utilisez Cloudflare, vous pouvez créer une règle WAF qui bloque les requêtes XML-RPC à la périphérie, avant qu'elles n'atteignent votre serveur. Allez dans Security > WAF > Custom Rules et créez une règle :

Nom de la règle : Block XML-RPC
Expression : (http.request.uri.path contains "/xmlrpc.php")
Action : Block

C'est la méthode de blocage la plus efficace car Cloudflare gère la requête sur ses serveurs en périphérie. Votre serveur d'origine ne voit jamais le trafic. Si vous devez autoriser Jetpack, ajoutez une exception pour les plages d'adresses IP d'Automattic.

Configuration de fail2ban pour la force brute XML-RPC

Si vous gérez votre propre serveur (VPS ou dédié), vous pouvez utiliser fail2ban pour bannir automatiquement les adresses IP qui ciblent à plusieurs reprises xmlrpc.php. Créez un fichier de filtre dans /etc/fail2ban/filter.d/wordpress-xmlrpc.conf :

[Definition]
failregex = ^<HOST> .* "POST .*xmlrpc.php.*" (200|403)
ignoreregex =

Puis ajoutez une jail dans /etc/fail2ban/jail.local :

[wordpress-xmlrpc]
enabled = true
port = http,https
filter = wordpress-xmlrpc
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 60
bantime = 3600

Cette configuration bannit toute adresse IP qui effectue plus de 5 requêtes vers xmlrpc.php en 60 secondes, en les bloquant pendant une heure. Ajustez les valeurs en fonction de vos modèles de trafic.

XML-RPC vs API REST : comparaison de sécurité

Comprendre pourquoi l'API REST est plus sécurisée aide à expliquer pourquoi XML-RPC devrait être abandonné :

Authentification : l'API REST prend en charge plusieurs méthodes d'authentification (cookie, mots de passe d'application, OAuth) et dispose d'une vérification de nonce intégrée. XML-RPC envoie les identifiants en clair dans le corps XML à chaque requête.
Limitation de débit : les requêtes de l'API REST peuvent être limitées par point d'accès. La méthode multicall de XML-RPC rend la limitation de débit par requête inefficace.
Permissions : l'API REST respecte les vérifications de capacités WordPress et fournit des callbacks d'autorisation granulaires pour chaque point d'accès. XML-RPC a un contrôle d'accès plus grossier.
Validation des entrées : les points d'accès de l'API REST utilisent une validation d'entrée basée sur un schéma. XML-RPC repose sur les implémentations individuelles des méthodes pour la validation.
Pas d'équivalent multicall : l'API REST n'a pas de point d'accès par lots qui permet de regrouper des centaines de tentatives d'authentification dans une seule requête.

Vérifiez si vous avez encore besoin de XML-RPC avant de le désactiver

Avant de désactiver XML-RPC, vérifiez qu'aucun de vos services actifs ne le requiert :

Jetpack : certaines fonctionnalités de Jetpack communiquent encore via XML-RPC. Si vous utilisez Jetpack, testez votre site après avoir désactivé XML-RPC. Si des fonctionnalités cassent, vous devrez peut-être autoriser les adresses IP d'Automattic ou utiliser la méthode de liste d'autorisation au niveau serveur présentée ci-dessus.
Application mobile WordPress : les versions actuelles de l'application mobile WordPress utilisent l'API REST. Seules les très anciennes versions (avant 2019) utilisaient XML-RPC. Si votre application fonctionne bien, vous n'avez pas besoin de XML-RPC.
Intégrations IFTTT ou Zapier : certaines anciennes intégrations avec des services d'automatisation utilisaient XML-RPC. Vérifiez si vos automatisations fonctionnent toujours après désactivation.
Windows Live Writer ou autres éditeurs de bureau : ces outils anciens utilisaient XML-RPC pour la publication. Si vous en utilisez encore un, envisagez de passer à l'éditeur de blocs WordPress ou à une alternative basée sur l'API REST.

Vérifier que XML-RPC est désactivé

Après avoir appliqué votre méthode choisie, vérifiez que XML-RPC est réellement bloqué :

# Devrait retourner 403 Forbidden ou connexion refusée
curl -s -o /dev/null -w "%{http_code}" -X POST
  https://yoursite.com/xmlrpc.php
  -H "Content-Type: text/xml"
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Si vous obtenez un code de statut 403, XML-RPC est bloqué. Si vous obtenez toujours 200, votre méthode de blocage ne fonctionne pas correctement. Vérifiez votre configuration et assurez-vous que le serveur a été redémarré (pour Nginx) ou que les modifications de .htaccess sont prises en compte (pour Apache, assurez-vous que AllowOverride est activé).

Vous pouvez également lancer une analyse InspectWP. La section sécurité détecte si XML-RPC est accessible et le signale comme un risque potentiel s'il répond aux requêtes.