Durcir WordPress sans plugin : 10 étapes manuelles que tout administrateur doit connaître

Résumé

De nombreux propriétaires de sites WordPress comptent sur les plugins de sécurité comme seule défense, mais cela peut créer un faux sentiment de sécurité. Une installation WordPress véritablement durcie nécessite des configurations manuelles qu'aucun plugin ne peut remplacer. Cet article fournit 10 mesures de durcissement concrètes, étape par étape, que vous pouvez mettre en œuvre immédiatement sans aucun plugin. De la définition des bonnes permissions de fichiers à la désactivation de XML-RPC, chaque étape traite une vulnérabilité spécifique. Vous apprendrez à verrouiller votre wp-config.php, supprimer le parcours des répertoires, et plus encore. Suivre ces étapes réduira considérablement votre surface d'attaque, même si vous continuez à utiliser des plugins de sécurité comme couche supplémentaire. À la fin, vous aurez un site WordPress manuellement durci et bien plus résistant aux attaques courantes.

Introduction

Vous avez installé un plugin de sécurité populaire, configuré le pare-feu et effectué des analyses régulières. Pourtant, votre site WordPress peut toujours être vulnérable. Les plugins de sécurité sont précieux, mais ils négligent souvent les points d'entrée faciles que le durcissement manuel détecte. Compter uniquement sur les plugins, c'est comme verrouiller votre porte d'entrée mais laisser les fenêtres ouvertes. Dans cet article, vous apprendrez 10 étapes de durcissement manuel que tout administrateur WordPress devrait effectuer, quels que soient les plugins utilisés. Ces étapes ne nécessitent aucune compétence en codage et peuvent être réalisées en moins d'une heure. Commençons à fortifier votre site dès la base.

1. Définir les bonnes permissions de fichiers

L'une des erreurs de configuration les plus courantes est de définir des permissions trop permissives pour les fichiers et dossiers. Idéalement, tous les fichiers doivent être en 644 et les dossiers en 755. Le fichier wp-config.php est particulièrement sensible—définissez-le à 440 ou 400 après l'installation. Utilisez un client FTP ou le gestionnaire de fichiers de votre hébergeur pour ajuster les permissions. Si vous n'êtes pas sûr de vos réglages actuels, effectuez un audit rapide à l'aide d'un script ou vérifiez en ligne de commande avec find /path -type f -exec chmod 644 {} \; et find /path -type d -exec chmod 755 {} \;. Ce simple changement empêche les utilisateurs non autorisés de lire ou modifier des fichiers critiques.

2. Désactiver l'édition de fichiers depuis le tableau de bord

Par défaut, WordPress permet aux administrateurs de modifier les fichiers de thèmes et de plugins directement depuis le panneau d'administration. Si un attaquant accède à un compte administrateur, il peut injecter du code malveillant. Désactivez cette fonctionnalité en ajoutant la ligne suivante à votre fichier wp-config.php :

define('DISALLOW_FILE_EDIT', true);

Cela n'affecte pas votre capacité à télécharger des thèmes ou des plugins—cela supprime uniquement l'éditeur de fichiers intégré. Utilisez un IDE ou FTP pour les modifications légitimes.

3. Désactiver le parcours des répertoires

Si le parcours des répertoires est activé, n'importe qui peut lister tous les fichiers de votre dossier wp-content/uploads, exposant potentiellement des données privées. Évitez cela en ajoutant cette ligne à votre fichier .htaccess (Apache) ou configuration équivalente :

Options -Indexes

Pour Nginx, ajoutez autoindex off; dans le bloc serveur. Testez en visitant une URL de répertoire ; vous devriez voir une erreur 403 Forbidden au lieu d'une liste de fichiers.

4. Désactiver XML-RPC

XML-RPC est un ancien protocole utilisé pour la publication à distance et les rétroliens. C'est un vecteur courant d'attaques par force brute et d'amplification DDoS. À moins que vous n'en ayez absolument besoin (par exemple, pour le plugin Jetpack ou une application mobile), désactivez-le complètement. Ajoutez ceci à votre .htaccess :

# Bloquer les requêtes WordPress xmlrpc.php
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Sinon, utilisez un plugin ou le pare-feu de votre hébergeur pour bloquer l'accès. Après désactivation, testez que votre site fonctionne toujours—la plupart des plugins modernes ne dépendent plus de XML-RPC.

5. Supprimer les thèmes et plugins inutilisés

Chaque thème ou plugin supplémentaire augmente votre surface d'attaque. Même désactivés, des codes obsolètes peuvent encore être exploités. Supprimez les thèmes que vous n'utilisez pas activement et retirez les plugins qui ne sont plus nécessaires. Ceci est particulièrement important pour les plugins abandonnés qui ne reçoivent plus de mises à jour. Pour un guide de nettoyage étape par étape, consultez notre article sur le danger caché des plugins WordPress abandonnés.

6. Changer le préfixe des tables de base de données

Par défaut, WordPress utilise wp_ comme préfixe de table dans la base de données. C'est largement connu et facilite les attaques par injection SQL. Changez le préfixe pour quelque chose d'unique lors de l'installation. Si votre site est déjà en ligne, vous pouvez toujours le changer—bien que cela demande plus d'efforts. Utilisez un plugin comme "Change Table Prefix" ou faites-le manuellement via phpMyAdmin :

1. Exportez votre base de données.
2. Renommez toutes les tables avec un nouveau préfixe (par exemple, mysec_).
3. Mettez à jour wp-config.php avec le nouveau préfixe.
4. Mettez à jour les tables options et usermeta où l'ancien préfixe est utilisé.

Effectuez toujours une sauvegarde avant d'essayer.

7. Limiter les tentatives de connexion

Les attaques par force brute sont le moyen le plus courant pour les attaquants d'obtenir un accès. WordPress n'a pas de limitation intégrée des tentatives de connexion. Implémentez cela manuellement en ajoutant du code au fichier functions.php de votre thème ou, mieux encore, utilisez un plugin must-use. Sinon, votre hébergeur peut offrir cette fonctionnalité via le panneau de contrôle. Si vous préférez un plugin, choisissez-en un léger et bien codé. Pour une stratégie plus large de réponse aux incidents, consultez notre workflow de correction de sécurité WordPress.

8. Changer le nom d'utilisateur administrateur

N'utilisez jamais "admin" comme nom d'utilisateur—c'est la première supposition dans toute attaque par force brute. Si vous avez déjà un compte avec ce nom d'utilisateur, créez un nouveau compte administrateur avec un nom unique, puis supprimez l'ancien. Envisagez également d'utiliser une adresse e-mail pour vous connecter au lieu d'un nom d'utilisateur.

9. Renforcer les sels et clés de base de données

WordPress utilise des sels et des clés pour crypter les sessions utilisateur et les cookies. S'ils sont compromis, les attaquants peuvent falsifier des sessions. Générez de nouveaux sels forts en utilisant le générateur de clés WordPress. Copiez la sortie et remplacez les lignes correspondantes dans votre wp-config.php. Faites-le périodiquement, surtout après un incident de sécurité.

10. Activer les mises à jour automatiques pour le noyau

Garder le noyau WordPress à jour est crucial. Activez les mises à jour automatiques pour les versions mineures et majeures en ajoutant ceci à wp-config.php :

define('WP_AUTO_UPDATE_CORE', true);

Pour les versions majeures, vous pouvez d'abord tester sur un site de staging, mais ne retardez pas les mises à jour de sécurité. Combinez cela avec des vérifications manuelles régulières des mises à jour de plugins et de thèmes.

Conclusion

Le durcissement manuel est le fondement d'un site WordPress sécurisé. Ces 10 étapes traitent des vulnérabilités courantes que les scanners et les plugins négligent souvent. En les mettant en œuvre, vous réduisez votre surface d'attaque et gagnez en tranquillité d'esprit. N'oubliez pas que la sécurité est un processus continu—revenez périodiquement sur ces configurations. Pour une approche complète, consultez notre guide proactif d'audit de sécurité WordPress. Commencez dès aujourd'hui avec une étape, et construisez à partir de là. La sécurité de votre site dépend des actions que vous prenez maintenant.