Gestion de l’obsolescence et sécurité : un exemple pour WordPress

Comprendre l’utilité passée et les risques actuels du fichier xmlrpc.php, ainsi que les bonnes pratiques pour sécuriser votre site.

Le fichier xmlrpc.php est un composant historique de WordPress. Bien qu’il ait été essentiel il y a quelques années, son utilité a largement diminué avec l’évolution de la plateforme. Ce fichier est aujourd’hui souvent perçu comme une porte dérobée pour les attaques informatiques, rendant sa gestion cruciale pour la sécurité de votre site.

Cependant, ce cas n’est pas isolé. De nombreux outils ou fonctionnalités peuvent devenir obsolètes ou présenter des risques avec le temps. Il est donc indispensable de maintenir une vigilance constante pour identifier et traiter ces failles potentielles.

Dans cet article, nous allons décrire brièvement le rôle historique de xmlrpc.php, examiner les risques qu’il représente et mettre en lumière des solutions pour le désactiver ou le sécuriser. Ceci, tout en soulignant l’importance de l’adoption d’alternatives modernes.

Qu’est-ce que xmlrpc.php ?

Le fichier xmlrpc.php est une interface permettant à WordPress de communiquer avec d’autres services ou applications via le protocole XML-RPC. À l’origine, il facilitait des fonctionnalités comme :

  • la publication de contenu via des outils tiers (logiciels de bureautique, scripts automatiques, etc.) ;
  • la gestion mobile des sites, à l’image de l’ancienne application WordPress pour smartphones.

Depuis la création de l’API REST de WordPress, plus moderne et sécurisée, le fichier xmlrpc.php a perdu son utilité. Pour la majorité des personnes administrant un site WordPress, il est même désormais considéré comme obsolète.

Pourquoi xmlrpc.php est-il problématique ?

Ce fichier présente aujourd’hui des failles qui en font une cible privilégiée pour les cyberattaques.

  • Attaques par force brute : des individus malintentionnés peuvent exploiter le fichier pour tenter un nombre illimité de connexions, en combinant des noms d’utilisateur et mots de passe.
  • Amplification des attaques DDoS : certaines fonctionnalités de xmlrpc.php permettent d’envoyer de nombreuses requêtes en un seul appel, multipliant ainsi la charge sur le serveur.
  • Exploitation des failles logicielles : si votre WordPress ou vos extensions ne sont pas à jour, ce fichier peut être utilisé pour exécuter des commandes malveillantes.

Comment désactiver xmlrpc.php ?

Heureusement, désactiver ce fichier est à la fois simple et sans impact pour la majorité des sites WordPress. Voici différentes méthodes adaptées à vos besoins.

  1. En modifiant le fichier .htaccess (solution préférée)

Si vous avez accès aux fichiers de votre site, vous pouvez empêcher les requêtes vers xmlrpc.php en ajoutant les lignes suivantes dans le fichier .htaccess (situé à la racine de votre site) :

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

Avantage : méthode directe et légère.

Inconvénient : nécessite une certaine prudence, car une erreur dans le fichier .htaccess peut affecter l’ensemble du site.

  • Via un plugin

Vous recherchez une solution clés en main ? Des extensions comme Disable XML-RPC-API permettent de désactiver rapidement xmlrpc.php sans toucher au code.

Avantage : facilité et gain de temps.

Inconvénient : dépendance à un plugin supplémentaire.

  • En configurant votre serveur

Pour les personnes administratrices disposant d’un hébergement dédié ou d’un VPS, il est possible de bloquer l’accès à xmlrpc.php au niveau du serveur. Par exemple, sur Apache :

<FilesMatch “xmlrpc\.php$”>    
Require all denied
</FilesMatch>

Ou sur Nginx :

location = /xmlrpc.php {
    deny all;
}

Avantage : solution idéale pour les environnements à forte charge.

Inconvénient : requiert des connaissances techniques.

Quelles sont les alternatives à xmlrpc.php ?

Plusieurs solutions simples peuvent être envisagées si vous avez besoin des fonctionnalités offertes par xmlrpc.php.

  1. Utiliser l’application mobile WordPress moderne

L’application officielle WordPress pour iOS et Android utilise désormais l’API REST au lieu de xmlrpc.php. Assurez-vous que votre site est configuré correctement pour permettre cette transition. La plupart des hébergements récents, comme ceux proposés par OVHcloud, supportent cette fonctionnalité par défaut.

  • Adopter des outils compatibles avec l’API REST

De nombreuses solutions de publication à distance ont été mises à jour pour utiliser l’API REST, qui est plus sécurisée et mieux adaptée aux besoins actuels. Vérifiez si vos outils favoris offrent cette compatibilité et, le cas échéant, mettez-les à jour.

  • Sécuriser xmlrpc.php en cas de besoin spécifique (en dernier recours)

Si vous ne pouvez vraiment pas vous passer de xmlrpc.php, il est crucial de limiter son exposition aux menaces. Voici quelques bonnes pratiques :

  • restreindre l’accès à certaines adresses IP via .htaccess ou la configuration serveur ;
  • utiliser un plugin de sécurité pour limiter les requêtes XML-RPC (ex. le nombre de connexions en un temps donné) ;
  • mettre en place une authentification forte, comme l’authentification à deux facteurs, pour renforcer la sécurité des connexions.

Cette solution est considérée comme non recommandée, car elle laisse tout de même une surface d’attaque accessible. Elle doit être réservée aux cas où l’utilisation de xmlrpc.php est indispensable. Gardez aussi à l’esprit que ces ajustements ne remplacent pas une migration vers des outils modernes comme l’API REST.

Protégez votre site WordPress tout en restant à jour

Vous connaissez désormais mieux le rôle historique et les enjeux de sécurité liés au fichier xmlrpc.php. N’oubliez pas que la sûreté de votre site repose sur une vigilance constante : surveillez les mises à jour de WordPress et de ses extensions, lisez attentivement leurs notes de version pour repérer tout changement susceptible d’affecter la sécurité de votre environnement.

Besoin d’un coup de main supplémentaire ? Rejoignez notre communauté sur Discord ou consultez notre documentation WordPress pour aller plus loin dans la sécurisation et l’optimisation de votre site.

Christophe Brunet
+ posts
+ posts

Technical Marketing Specialist @OVHcloud

About 20 years of experience in HW storage/backup/replication.....