# XML-RPC sur WordPress : faut-il vraiment le désactiver en 2020 ?

> XML-RPC sert Jetpack et l'appli mobile, mais aussi le brute force et le DDoS par pingback. Voici comment trancher sans rien casser.

- Auteur : Clément Hadrot
- Publié le : 2020-06-17
- Mis à jour le : 2020-06-17
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/xml-rpc-faut-il-desactiver/

## L’essentiel

- system.multicall permet de tester des centaines de mots de passe en une requête
- Le pingback peut être détourné pour un DDoS réflexif
- xmlrpc_enabled et un blocage serveur ciblé règlent le problème sans casser Jetpack

`xmlrpc.php` est un fichier présent à la racine de toute installation WordPress, et pourtant la majorité des propriétaires de site ignorent son existence jusqu'au jour où leur hébergeur les alerte d'un pic de trafic suspect dessus. C'est l'un des sujets qui reviennent le plus souvent en audit : faut-il le désactiver, au risque de casser des fonctionnalités utiles, ou faut-il vivre avec le risque ?

La réponse n'est ni « toujours » ni « jamais », elle dépend de ce que vous utilisez réellement. Passons en revue à quoi sert XML-RPC, quels sont ses vrais risques, et comment le désactiver proprement quand c'est justifié, sans surprise pour vos utilisateurs.

## À quoi sert XML-RPC concrètement

XML-RPC est un protocole permettant à des applications externes de communiquer avec WordPress via des requêtes HTTP structurées en XML, sans passer par l'interface web classique. Plusieurs usages légitimes s'appuient dessus :

- **Jetpack**, l'extension d'Automattic, utilise XML-RPC pour synchroniser les statistiques, les sauvegardes et plusieurs fonctionnalités avec les serveurs WordPress.com ;
- L'application mobile officielle WordPress s'en sert pour publier et gérer du contenu depuis un smartphone ;
- Certains outils tiers de publication automatisée ou de gestion multi-sites y font encore appel ;
- Le mécanisme de **pingback**, qui notifie un autre site quand vous créez un lien vers lui, transite aussi par là.

Si vous n'utilisez ni Jetpack, ni l'application mobile, ni d'outil tiers connu s'appuyant dessus, XML-RPC ne vous rend aujourd'hui quasiment aucun service.

## Les deux risques principaux

Le premier risque, le plus documenté, concerne la méthode `system.multicall`. Elle permet de grouper plusieurs appels XML-RPC dans une seule requête HTTP. Un attaquant peut l'utiliser pour tester des centaines de couples identifiant/mot de passe en une poignée de requêtes, contournant au passage les protections de limitation de tentatives qui comptent souvent par requête HTTP plutôt que par tentative de connexion réelle.

> L'essentiel à retenir : system.multicall permet de tester des centaines de mots de passe en une requête ; Le pingback peut être détourné pour un DDoS réflexif ; xmlrpc_enabled et un blocage serveur ciblé règlent le problème sans casser Jetpack

Le second risque touche le pingback. La méthode `pingback.ping` accepte une URL cible fournie par l'appelant et fait effectuer une requête HTTP par le serveur WordPress vers cette URL. Détournée à grande échelle sur de nombreux sites WordPress simultanément, cette mécanique a servi par le passé à générer des attaques par déni de service réflexif contre un site tiers, chaque WordPress agissant comme relais sans le savoir.

## Désactiver XML-RPC proprement avec un filtre

La méthode la plus propre côté WordPress consiste à utiliser le filtre `xmlrpc_enabled`, qui désactive l'ensemble du protocole sans toucher aux fichiers cœur :

```
add_filter( 'xmlrpc_enabled', '__return_false' );
```

À placer dans le fichier `functions.php` d'un thème enfant, ou mieux, dans une petite extension dédiée pour que le réglage survive à un changement de thème. Ce filtre retourne une erreur explicite à toute tentative d'appel XML-RPC, ce qui est plus propre qu'un blocage brutal côté serveur pour les outils qui vérifient la disponibilité du service avant d'appeler une méthode.

## Le cas Jetpack : ne pas tout bloquer aveuglément

Si Jetpack est actif sur le site, désactiver XML-RPC via le filtre ci-dessus le casse complètement, car Jetpack en dépend pour la synchronisation avec WordPress.com. Dans ce cas, deux options raisonnables :

- Garder XML-RPC actif, mais désactiver spécifiquement les pingbacks, qui ne sont pas nécessaires à Jetpack :

```
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );
```

- Ou restreindre l'accès à `xmlrpc.php` au niveau du serveur web à une liste d'adresses IP connues, si Jetpack et les usages légitimes proviennent d'IP identifiables, ce qui est rarement pratique à maintenir.

## Blocage côté serveur : une alternative plus radicale

Quand XML-RPC n'est utilisé par aucune extension, un blocage direct au niveau du serveur web est souvent plus efficace qu'un filtre PHP, car la requête n'atteint même pas WordPress. Sur Apache, un bloc dans `.htaccess` suffit :

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

Sur Nginx, une directive équivalente dans le bloc `server` :

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

> Avant de bloquer quoi que ce soit côté serveur, je vérifie toujours dans les extensions actives si Jetpack, WooCommerce ou un connecteur tiers en dépend. Un blocage trop rapide au niveau du serveur, invisible depuis l'administration WordPress, peut faire perdre un temps fou à diagnostiquer une synchronisation cassée.

## En résumé

XML-RPC n'est ni un vestige inutile ni une fonctionnalité à conserver aveuglément. La bonne approche consiste à vérifier ce qui en dépend réellement sur votre site, puis à choisir le niveau de blocage adapté : filtre PHP pour une désactivation complète et propre, désactivation ciblée du pingback si Jetpack est actif, ou blocage serveur quand aucun usage légitime n'existe. Dans tous les cas, mieux vaut fermer cette porte que la laisser ouverte par défaut sans y avoir réfléchi.