Sécuriser un site WordPress : les mesures qui comptent

Les conseils pour sécuriser un site WordPress se ressemblent tous : mettez à jour, choisissez un bon mot de passe, installez une extension. C’est exact et c’est insuffisant, parce que rien là-dedans ne se vérifie. Voici les mesures qui se constatent, avec les fichiers, les valeurs et les adresses à contrôler, et à la fin celles qui rassurent sans rien protéger.

Le premier trou : votre site publie le nom de l’administrateur

C’est la faiblesse la plus répandue, et presque personne ne la vérifie. Une attaque par force brute a besoin de deux éléments, un identifiant et un mot de passe. Par défaut, WordPress donne le premier gratuitement.

https://votre-site.fr/wp-json/wp/v2/users
https://votre-site.fr/?author=1

La première adresse renvoie la liste des comptes ayant publié, en JSON. La seconde redirige vers la page d’archive de l’auteur, dont l’adresse contient son identifiant de connexion. Ouvrez-les sur votre propre site : si un nom apparaît, la moitié du travail de l’attaquant est déjà faite.

La correction consiste à fermer l’exposition des utilisateurs dans l’API REST et à neutraliser la redirection par auteur. Beaucoup d’extensions de sécurité le proposent, mais peu l’activent par défaut. Vérifiez le résultat sur les deux adresses ci-dessus plutôt que de vous fier à une case cochée.

Les constantes de wp-config.php qui changent quelque chose

Le fichier wp-config.php accepte des constantes qui ferment des portes entières, en une ligne chacune, sans extension.

define( 'DISALLOW_FILE_EDIT', true );   // supprime l'editeur de code de l'admin
define( 'FORCE_SSL_ADMIN', true );      // impose HTTPS sur toute l'administration
define( 'WP_DEBUG', false );            // coupe l'affichage des erreurs en production

La première est la plus importante et la moins utilisée. L’éditeur de fichiers intégré permet de modifier le code du thème depuis le tableau de bord : un compte administrateur compromis devient alors un accès complet au serveur, sans avoir besoin du FTP. La désactiver transforme une prise de contrôle de compte en simple nuisance.

Les permissions de fichiers, avec les bons chiffres

Élément	Permission	Ce que cela signifie
Dossiers	755	Le propriétaire écrit, les autres lisent et traversent
Fichiers	644	Le propriétaire écrit, les autres lisent seulement
wp-config.php	640 ou 600	Il contient vos identifiants de base de données

La règle à retenir : aucun fichier ne doit être en 777. C’est la valeur que les tutoriels recommandent pour « régler un problème d’upload », et elle autorise n’importe quel processus de la machine à réécrire votre code. Si un dossier a besoin de 777 pour fonctionner, c’est le propriétaire du fichier qui est mal réglé, pas la permission.

XML-RPC, l’amplificateur d’attaques

Le fichier xmlrpc.php est une interface ancienne, conservée pour la compatibilité. Elle expose une méthode qui permet de grouper plusieurs appels dans une seule requête.

La conséquence est simple à comprendre : au lieu d’envoyer mille tentatives de connexion, donc mille requêtes visibles et limitables, un attaquant en envoie quelques-unes contenant chacune des centaines d’essais. Toutes les protections qui comptent les tentatives sur la page de connexion sont contournées, et vos journaux ne montrent presque rien.

Si vous ne publiez pas depuis une application mobile ou un outil tiers qui en dépend, bloquez l’accès à ce fichier au niveau du serveur web. C’est la mesure qui a le meilleur rapport entre effort et effet sur un WordPress ordinaire.

Les extensions, premier vecteur réel

Le cœur de WordPress est audité par des milliers de personnes. Les extensions, non. C’est par elles que passent la grande majorité des compromissions, et la règle utile n’est pas « n’installez que des extensions réputées » mais celle-ci :

• Désinstallez, ne désactivez pas. Une extension désactivée reste sur le disque et reste exploitable : son code est toujours accessible par une requête directe.
• Regardez la date de dernière mise à jour avant le nombre d’installations. Une extension populaire mais abandonnée depuis deux ans est plus dangereuse qu’une extension confidentielle et maintenue.
• Comptez-les. Chaque extension est une surface d’attaque et une dépendance de plus. Une installation qui en compte quarante n’est pas maintenable.
• Supprimez aussi les thèmes inutilisés, y compris les thèmes par défaut de WordPress que personne n’utilise et que personne ne met à jour.

Ce qu’il faut faire en cas de compromission

Un point que les guides de prévention omettent presque toujours : changer les mots de passe ne déconnecte pas l’attaquant. Les sessions ouvertes reposent sur des cookies signés par les clés secrètes stockées dans wp-config.php.

Tant que ces clés ne changent pas, une session volée reste valide. Régénérez-les : WordPress fournit un générateur officiel, et le simple remplacement du bloc de clés dans wp-config.php invalide immédiatement toutes les sessions du site, y compris la vôtre et celle de l’intrus.

Ensuite seulement, restaurez une sauvegarde antérieure à l’infection. Encore faut-il en avoir une dont la restauration a été testée, ce que nous détaillons dans notre guide sur les sauvegardes automatiques d’un serveur.

La base technique compte autant que le CMS

Un WordPress parfaitement réglé sur une machine ouverte à tous les vents ne protège rien. Les mesures qui relèvent du serveur, accès par clé, pare-feu restrictif, correctifs automatiques et certificat valide, sont décrites dans notre article sur la sécurité d’un serveur, et le rôle exact d’un pare-feu dans cet ensemble est précisé dans notre article sur les pare-feu.

Un réseau de diffusion de contenu absorbe par ailleurs une partie des requêtes hostiles avant qu’elles n’atteignent l’hébergement, en plus d’accélérer l’affichage : nous expliquons son fonctionnement dans notre article sur l’utilité d’un CDN. Et si vous basculez d’hébergement à cette occasion, la coupure se prépare comme décrit dans notre article sur la propagation DNS.

Trois mesures qui rassurent sans protéger

• Changer l’adresse de connexion. Cela allège vos journaux, ce qui a une valeur pratique réelle. Cela n’arrête personne : l’adresse se retrouve par de nombreux indices, et l’attaque par XML-RPC ne passe de toute façon pas par cette page.
• Masquer le numéro de version de WordPress. Un scanner détermine la version par le comportement des fichiers, pas par la balise que vous retirez.
• Empiler les extensions de sécurité. Deux extensions qui filtrent les mêmes requêtes se gênent, consomment deux fois et produisent des journaux contradictoires. Une seule, bien réglée, vaut mieux.

Ces extensions alourdissent d’ailleurs le site, et un site plus lourd se supervise plus mal. Les arbitrages entre protection et rapidité sont abordés dans notre article sur l’optimisation des performances sans changer d’hébergement.

Questions fréquentes sur la sécurité WordPress

Comment sécuriser un site WordPress efficacement ?

En fermant d’abord ce qui s’expose sans raison : la liste des utilisateurs dans l’API REST, l’éditeur de fichiers de l’administration via DISALLOW_FILE_EDIT, et l’accès à xmlrpc.php si aucun outil externe n’en dépend. Ces trois mesures se vérifient en quelques minutes.

Quelles permissions faut-il donner aux fichiers WordPress ?

755 pour les dossiers, 644 pour les fichiers, et 640 ou 600 pour wp-config.php qui contient les identifiants de base de données. Aucun fichier ne doit être en 777, quelle que soit la raison invoquée.

Faut-il désactiver xmlrpc.php sur WordPress ?

Oui si aucune application mobile ni aucun outil tiers ne publie sur le site. Ce fichier permet de grouper des centaines de tentatives de connexion dans une seule requête, ce qui contourne les protections qui comptent les échecs sur la page de connexion.

Changer son mot de passe suffit-il après un piratage ?

Non. Les sessions ouvertes reposent sur des cookies signés par les clés secrètes de wp-config.php. Tant que ces clés ne sont pas régénérées, une session volée reste valide malgré le changement de mot de passe.

Faut-il changer l'URL de connexion à WordPress ?

Cela réduit le bruit dans les journaux, sans constituer une protection. L’adresse se retrouve par de nombreux indices, et les attaques passant par XML-RPC n’utilisent pas cette page.