La plupart des tutoriels de sécurité WordPress finissent par vendre un plugin. Pourtant, quelques réglages manuels dans les fichiers du site suffisent à bloquer une grande partie des attaques courantes. Changer le préfixe des tables de la base de données, masquer la version affichée, supprimer l’utilisateur « admin » et désactiver l’édition de fichiers depuis le back-office demandent une poignée de minutes. Aucune dépense, aucune dépendance à un éditeur tiers. Voici comment durcir votre installation WordPress avec des modifications précises sur wp-config.php et .htaccess.
Le préfixe de tables wp_, cible silencieuse des attaquants
WordPress crée ses tables de base de données avec un préfixe visible : wp_. Un attaquant qui connaît ce nom peut tenter des injections SQL ciblées, car il sait exactement où chercher les informations sensibles, et cette simple connaissance, obtenue sans aucun effort, lui évite de tâtonner longuement à chaque tentative sur la base de données.
La parade tient en une ligne dans wp-config.php : remplacer la valeur de $table_prefix par une chaîne courte et imprononçable. Cette modification s’effectue avant l’installation, mais rattraper un site existant reste possible avec un peu de rigueur.
Franchement, beaucoup de sites tournent encore avec ce préfixe par défaut sans le savoir. Modifier cette valeur demande d’éditer le fichier wp-config.php à la main, puis de renommer chaque table dans la base. Les outils comme phpMyAdmin rendent l’opération plus simple, mais il faut passer le site en maintenance pendant l’intervention. Le jeu en vaut la chandelle : un préfixe aléatoire complique sérieusement le travail d’un automate.
Masquer la version de WordPress et neutraliser le compte admin
Chaque installation WordPress affiche sa version dans le code source via une balise meta. Cette information paraît anodine, mais elle oriente un attaquant vers les failles connues de cette version précise. Supprimer cette balise demande quelques lignes dans le fichier functions.php de votre thème, ou une règle .htaccess qui retire la mention du meta generator, une opération à la portée de tout utilisateur habitué à copier-coller du code, même sans être développeur. Ces manipulations ne nécessitent aucun plugin payant.
Le compte administrateur par défaut s’appelle « admin ». WebSentinel a observé que ce simple nom d’utilisateur concentre une large part des attaques par force brute, comme le rappelle samuelnasri.com. Créer un nouveau compte avec un identifiant original, lui accorder les droits d’administrateur, puis supprimer l’ancien « admin » bloque une grande partie des tentatives automatisées, car les robots de force brute ciblent d’abord ce nom devenu trop prévisible sur tous les sites WordPress du monde sans exception.
Plusieurs réglages manuels passent sous les radars des tutoriels classiques, alors qu’ils demandent moins d’efforts qu’une installation de plugin. Les voici regroupés, sans classement particulier, pour une application directe sur votre site. Ces ajustements ne coûtent rien, hormis quelques minutes de lecture et de copier-coller.
Les actions manuelles à ne pas négliger
- Modifier le préfixe de table wp_ dans wp-config.php avant toute installation.
- Une règle .htaccess pour bloquer l’accès direct à wp-config.php.
- Pourquoi laisser encore la version de WordPress visible dans le code source ?
- Créer un identifiant administrateur unique et supprimer « admin ».
- Interdire l’édition de fichiers dans le back-office avec une constante.
Désactiver l’édition de fichiers depuis le back-office
Le menu Apparence, puis l’option Éditeur de fichiers, donne accès au code du thème et des extensions depuis l’administration. Un simple compte compromis peut alors modifier n’importe quel fichier PHP, ajouter une porte dérobée ou supprimer des fonctionnalités. La constante DISALLOW_FILE_EDIT, placée dans wp-config.php, coupe cet accès en une seule ligne. Elle indique à WordPress de désactiver l’éditeur de fichiers pour tous les utilisateurs, y compris les administrateurs.
Cette désactivation ne supprime aucune fonctionnalité importante du site. Le back-office reste entièrement utilisable pour publier des articles, gérer les utilisateurs et installer des extensions fiables. Seul l’éditeur de code disparaît, ce qui gêne surtout les personnes qui modifient leur thème à la volée. Si vous devez changer un fichier, passez par un accès FTP ou SSH, bien plus encadré qu’une zone d’administration exposée, et cette habitude, une fois prise, vous protège aussi des modifications accidentelles pendant une mise à jour.
Verrouiller wp-config.php et .htaccess contre les regards indiscrets
Le fichier wp-config.php contient les identifiants de connexion à la base de données. S’il devient lisible par un visiteur, le site tombe immédiatement. Une règle dans .htaccess peut interdire l’accès direct à ce fichier : quelques lignes qui renvoient une réponse d’accès interdit. De même, protéger .htaccess lui-même évite qu’un attaquant ne le modifie pour désactiver vos protections. Ces fichiers jouent un rôle central dans la sécurité manuelle.
Certains hébergeurs placent wp-config.php hors de la racine web par défaut. Si ce n’est pas votre cas, déplacer ce fichier d’un niveau vers le haut complique la tâche d’un attaquant qui chercherait à le lire. WordPress accepte qu’on déplace wp-config.php, à condition que le fichier reste accessible au processus PHP. Cette opération demande de la prudence, mais elle renforce la protection sans toucher aux plugins.
Une protection durable sans dépendre d’un plugin
Durcir un site WordPress sans plugin payant revient à reprendre la main sur ses propres fichiers. Les réglages évoqués ici, du préfixe de tables à la désactivation de l’édition, forment une protection solide contre les attaques automatisées.
Le plus difficile n’est pas d’appliquer ces modifications, c’est de les garder en tête à chaque mise à jour ou migration. Un site qui néglige ces détails reste vulnérable, même avec un plugin de sécurité onéreux. Alors, combien de temps laisserez-vous encore le préfixe wp_ en place ?
