# Changer le préfixe des tables WordPress ne remplace jamais une vraie politique de mots de passe

> Modifier wp_ en un préfixe aléatoire ne ralentit ni une attaque par force brute ni un identifiant faible. Ce que cette pratique protège réellement, et ce qu'elle ne protège pas.

- Auteur : WordPress Développement
- Publié le : 2020-02-16
- Mis à jour le : 2020-02-16
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/prefixe-tables-wordpress-ne-remplace-pas-mots-de-passe/

## L’essentiel

- Le préfixe de table n'agit que contre l'injection SQL générique
- Il ne bloque ni la force brute ni un identifiant faible
- Une politique de mots de passe reste indispensable en parallèle

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.

> L'essentiel à retenir : Le préfixe de table n'agit que contre l'injection SQL générique ; Il ne bloque ni la force brute ni un identifiant faible ; Une politique de mots de passe reste indispensable en parallèle

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.