Un constat revient régulièrement dans les guides de sécurisation WordPress : remplacer le préfixe par défaut wp_ par une chaîne aléatoire comme xk29_ figurerait parmi les premières mesures à prendre. Cette recommandation, présentée seule, laisse penser qu’elle ferme une porte d’entrée importante. Ce n’est pas le cas.
Le préfixe de table est défini dans wp-config.php via la variable $table_prefix. Il sert uniquement à distinguer les tables d’une installation WordPress dans une base de données, notamment lorsque plusieurs installations partagent la même base. Il n’intervient à aucun moment dans le processus d’authentification d’un utilisateur.
Ce qu’on voit dans les guides de durcissement
La recommandation de changer le préfixe apparaît presque systématiquement à côté d’autres conseils plus substantiels : désactiver l’éditeur de thème, limiter les tentatives de connexion, activer une authentification à deux facteurs. Placée dans cette liste, elle donne l’impression d’appartenir à la même catégorie de mesures efficaces, alors que son mécanisme de protection est d’une nature totalement différente et beaucoup plus limitée.
Pourquoi c’est un problème de présentation, pas seulement de fond
Le préfixe personnalisé ne complique que les injections SQL génériques, celles qui supposent à l’aveugle le nom exact wp_users ou wp_options sans avoir d’abord découvert la structure réelle de la base. Une injection SQL bien construite commence justement par interroger le schéma de la base via des requêtes sur information_schema.tables, ce qui révèle le préfixe réel en une seule requête. Le gain de sécurité se limite donc à ralentir les tentatives les plus rudimentaires, sans effet sur une attaque un tant soit peu structurée.
Face à une attaque par force brute sur wp-login.php, le préfixe de table n’entre tout simplement jamais en jeu : le formulaire de connexion interroge la table des utilisateurs via l’API interne de WordPress, indépendamment de son nom réel. Un attaquant qui teste des couples identifiant et mot de passe n’a besoin de connaître aucun nom de table.
Ce que cette pratique ne remplace jamais
- Une politique de mots de passe robustes, avec une longueur minimale et l’interdiction des mots de passe déjà compromis, vérifiée côté serveur avant l’enregistrement.
- Une limitation du nombre de tentatives de connexion par identifiant et par adresse IP, qui ralentit réellement une attaque par force brute.
- Une authentification à deux facteurs, qui rend inutile un mot de passe deviné ou volé par ailleurs.
Quoi faire à la place
Concentrer l’effort de durcissement sur les mesures qui agissent directement sur le vecteur d’attaque réellement exploité. Pour une attaque par force brute sur le formulaire de connexion, cela signifie limiter les tentatives et exiger des mots de passe suffisamment longs. Pour une injection SQL, la seule protection fiable reste l’usage systématique de requêtes préparées via $wpdb->prepare(), jamais une obscurité de nommage.
Un préfixe de table personnalisé n’est pas une mesure de sécurité au sens strict : c’est, au mieux, une gêne mineure pour un script mal écrit.
Ce que révèle un changement de préfixe tardif
Modifier le préfixe d’une installation déjà en production, plutôt qu’au moment de son installation initiale, exige de renommer chaque table concernée, de mettre à jour la référence $table_prefix dans wp-config.php, et de vérifier qu’aucune requête personnalisée écrite ailleurs dans une extension ne référence encore l’ancien préfixe en dur. Cette opération, plus délicate qu’elle n’y paraît, illustre bien le décalage entre l’effort qu’elle demande et le gain de sécurité réel qu’elle procure : un effort de migration non négligeable, pour une protection qui reste marginale face à une injection SQL structurée.
Notre verdict
Changer le préfixe de table ne fait de mal à personne et peut rester une pratique par défaut lors d’une nouvelle installation. Mais la présenter comme une mesure de sécurité à part entière détourne l’attention des priorités réelles : mots de passe robustes, limitation des tentatives de connexion et requêtes préparées systématiques. Une checklist de durcissement qui place ce point au même niveau que ces trois-là mérite d’être révisée.
