Changer le préfixe des tables WordPress ne bloque pas les injections SQL

On te dira que changer le préfixe des tables WordPress, c’est la base de la sécurité. Que si tu laisses wp_, tu tends le bâton pour te faire battre. C’est une idée qui traîne dans les articles SEO depuis 2012, et elle est fausse sur le point qui compte le plus : les injections SQL.

J’ai hérité l’an dernier d’un site WordPress qui tournait avec un préfixe x7b2_ depuis 2019. Le propriétaire pensait avoir fait le nécessaire. Sauf que le thème sur mesure appelait wp_postmeta en dur dans trois fichiers. Deux extensions faisaient de même. Résultat : des logs d’erreur saturés de Table 'db.wp_postmeta' doesn't exist et un site qui perdait 12 % de ses ventes sans que personne ne le voie. Le changement de préfixe avait été fait à moitié, et le vrai risque, les injections SQL, n’avait pas été traité du tout.

Voici ce que le changement de préfixe protège réellement, ce qu’il ne protège pas, et comment le faire proprement quand l’opération a du sens.

Ce que le changement de préfixe protège réellement

Le préfixe des tables, c’est ce qui transforme wp_posts en monsite_posts. L’argument classique : un attaquant qui exploite une injection SQL doit connaître le nom des tables pour exfiltrer des données. S’il tente SELECT * FROM wp_users et que la table s’appelle xyz_users, la requête échoue.

C’est vrai. Mais uniquement pour les attaques scriptées de masse. Les bots qui scannent des milliers de sites en cherchant des noms de tables standards. Ces attaques-là, un préfixe non standard les bloque effectivement.

Le problème, c’est que l’injection SQL moderne ne fonctionne plus comme ça. Un attaquant qui a trouvé une faille exploitable ne va pas deviner le nom de la table. Il va utiliser les fonctions SQL qui exposent la structure de la base : information_schema.tables, SHOW TABLES, ou pire, une injection en aveugle qui reconstruit les données bit par bit sans avoir besoin d’aucun nom. Le préfixe ne protège pas contre ces techniques.

⚠️ Attention : Si ton site utilise un constructeur de pages ou des extensions qui stockent du SQL dans des champs de la base (shortcodes complexes, requêtes dynamiques), le préfixe personnalisé ne protège rien. L’injection passe par les valeurs, pas par les noms de tables.

Le préfixe personnalisé, c’est une mesure de dissuasion de bas niveau. Ça réduit le bruit de fond des attaques automatisées. Ça ne réduit pas le risque d’une attaque déterminée.

Les deux vrais motifs pour changer de préfixe

Il y a deux contextes où l’opération est pertinente, et aucun n’est « améliorer la sécurité contre les injections SQL ».

Premier cas : héberger plusieurs sites dans une base unique. Si tu as trois WordPress dans la même base MySQL, tu as besoin de préfixes distincts pour éviter les collisions. site1_posts, site2_posts, etc. C’est une contrainte d’architecture, pas de sécurité. Et c’est surtout vrai pour les multisites ou les hébergements mutualisés cheap qui limitent le nombre de bases.

Deuxième cas : migrer un site depuis un environnement où le préfixe était partagé. Tu récupères un dump SQL, tu le restaures sur un serveur qui héberge déjà d’autres WordPress avec le même préfixe. Là, tu changes pour éviter d’écraser les tables existantes.

Dans tous les autres cas, changer le préfixe sur un site existant est une opération chirurgicale dont le bénéfice sécurité est marginal comparé au risque de casse. Le vrai travail de sécurisation est ailleurs : valider et échapper chaque entrée utilisateur, systématiser $wpdb->prepare(), désactiver l’affichage des erreurs SQL en production, et maintenir WordPress et ses extensions à jour.

La procédure pas à pas sans casser le site en production

Si tu dois vraiment changer le préfixe, voici comment je procède sur un site en production. Pas de « 5 plugins pour changer votre préfixe en un clic ». Un plugin ne saura pas ce qui se passe dans ton thème sur mesure ni dans tes mu-plugins.

1. Sauvegarde complète. Un dump SQL, un tar.gz du répertoire WordPress. Stockés hors du serveur. Si tu sautes cette étape, la suite ne compte pas.

2. Inventaire des appels en dur à wp_. Dans le répertoire du thème et des extensions, un grep récursif :

grep -rn "wp_" --include="*.php" wp-content/themes/ wp-content/plugins/ | grep -v "wp_doing_ajax\|wp_date\|wp_parse_args"

Tu filtres les fonctions WordPress légitimes (wp_remote_get, etc.) pour ne garder que les appels explicites aux noms de tables. Chaque occurrence trouvée est un futur bug si tu ne la corriges pas.

3. Passage en mode maintenance. Un fichier .maintenance à la racine, ou une page statique servie par le serveur web. L’opération prend rarement plus de 5 minutes, mais une requête qui tombe pendant le renommage des tables, c’est un état incohérent.

4. Modification de wp-config.php. Tu changes la constante $table_prefix avec la nouvelle valeur. Pas de valeur par défaut, pas de wp_ déguisé.

5. Renommage des tables. Soit via WP-CLI si tu l’as :

wp db prefix nouveau_

Soit en SQL direct, table par table. La commande WP-CLI gère toutes les tables en une fois, y compris les tables créées par les extensions qui utilisent $wpdb->prefix. La méthode SQL manuelle est plus risquée parce que tu peux en oublier.

6. Purge agressive des caches. Vider l’OPcache PHP, purger le cache d’objets Redis ou Memcached s’il est actif, vider tous les caches de ton plugin de cache (WP Rocket, Flying Press, etc.), et supprimer le contenu du répertoire wp-content/cache/. Un cache d’objet qui sert encore des clés avec l’ancien préfixe, c’est des erreurs 500 ou des pages blanches.

7. Vérification. Tu parcours le site page par page : accueil, article, page, archive, back-office, page de connexion. Tu actives WP_DEBUG le temps du test. Tu surveilles le fichier de log d’erreurs PHP en temps réel :

tail -f wp-content/debug.log

La moindre occurrence de doesn't exist ou Base table or view not found t’indique une table non renommée ou un appel en dur dans le code.

💡 Conseil : Si tu migres aussi l’URL du site dans la foulée, utilise wp search-replace plutôt qu’un export SQL avec remplacement texte. Le sérialiseur PHP est sensible au nombre de caractères, et un remplacement naïf corrompt les données sérialisées stockées dans les options et les métadonnées.

Le point de douleur réel : les appels qui contournent $wpdb->prefix

J’ai mentionné le site avec x7b2_ qui perdait des ventes. La cause était simple à corriger, mais difficile à détecter : le développeur du thème avait écrit des requêtes SQL en dur. Pas par incompétence, plutôt par habitude de travailler sur un environnement mono-site où wp_ est une constante implicite.

Voici un exemple de ce qu’on trouve dans le code legacy d’un thème acheté sur ThemeForest en 2018 :

$query = "SELECT meta_value FROM wp_postmeta WHERE post_id = $post_id AND meta_key = 'prix_promo'";
$result = $wpdb->get_var($query);

Le préfixe est en dur. Change le préfixe des tables, cette requête retourne null en silence. Aucune erreur fatale, juste des données manquantes. L’extension de prix barrés ne s’affiche plus, les promotions sont invisibles, et le chiffre d’affaires baisse sans alerte.

La correction est mécanique : remplacer wp_postmeta par {$wpdb->postmeta} ou $wpdb->prefix . 'postmeta'. Le premier est plus lisible, le second est plus explicite pour quelqu’un qui ne connaît pas les propriétés de la classe wpdb.

Ce type de bug est d’autant plus vicieux qu’il peut survivre des mois sans être détecté. Les pages se chargent, le site fonctionne, mais une fonctionnalité périphérique est silencieusement cassée. Et comme le bug n’est pas dans les extensions mais dans le thème sur mesure, aucun test automatisé standard ne le détecte.

Pourquoi l’OPcache et le cache d’objets transforment l’opération en piège

WordPress moderne tourne presque toujours avec un cache d’OPcode et souvent avec un cache d’objets. Ces deux couches rendent le changement de préfixe plus risqué qu’il y a dix ans.

L’OPcache stocke le bytecode compilé des fichiers PHP. Si tu changes wp-config.php mais que l’OPcache sert l’ancienne version compilée pendant encore 30 secondes, ton site tourne avec l’ancien préfixe pendant que les tables ont déjà été renommées. Résultat : des erreurs 500 transitoires. Pas visibles en navigation superficielle, mais bien présentes dans les logs.

Un cache d’objets Redis, lui, stocke les résultats de requêtes SQL et les options sérialisées. Les clés Redis incluent souvent le préfixe des tables. Après renommage, les anciennes clés persistent jusqu’à leur expiration naturelle ou jusqu’à un FLUSHALL. Sans purge explicite, ton site peut servir des données partielles pendant plusieurs heures, avec des pages qui affichent le contenu d’avant la migration et d’autres qui plantent.

Ce n’est pas un edge case théorique. C’est le comportement standard d’un WordPress hébergé chez un hébergeur qui active Redis par défaut sur ses offres performance. La purge des caches n’est pas optionnelle, c’est la dernière étape obligatoire de la procédure. Et si tu gères ton infrastructure, assure-toi que la purge est bien atomique : pas de rechargement partiel où une extension recrée du cache avant que toutes les tables ne soient renommées.

Cette exigence de purge intégrale rappelle ce qu’on observe sur d’autres couches de performance : une opération locale peut casser une optimisation globale si on ne traite pas toutes les strates. Quand on bosse sur l’optimisation Core Web Vitals, on apprend vite qu’un cache partiellement vidé après une modification structurelle produit des métriques incohérentes pendant des heures.

Ce que le préfixe ne protège pas, et ce qui le fait vraiment

Pour clarifier le périmètre réel du changement de préfixe, voici ce que tu obtiens et ce que tu n’obtiens pas :

Le tableau est clair : le préfixe bloque une seule catégorie de menace, et c’est la moins sophistiquée. La défense réelle contre les injections SQL passe par l’utilisation stricte de $wpdb->prepare() et des requêtes préparées, la validation des entrées côté serveur, et une politique de moindre privilège sur les comptes MySQL.

Un site WordPress dont l’utilisateur MySQL a les droits DROP ou ALTER, c’est un site où une injection SQL réussie peut détruire des tables entières, préfixe personnalisé ou pas. La bonne pratique : un utilisateur MySQL avec SELECT, INSERT, UPDATE, DELETE uniquement, et des credentials distincts pour les opérations d’administration.

Changer le préfixe sur un site neuf : le seul moment où c’est gratuit

Sur un WordPress fraîchement installé, changer le préfixe ne coûte rien. Pas de tables à renommer, pas de code legacy à auditer, pas de cache à purger. Tu modifies wp-config.php avant la première installation, et WordPress crée les tables avec le nouveau préfixe dès le premier chargement.

C’est le seul moment où je le recommande sans réserve. Pas pour la sécurité, mais pour réduire la surface d’exposition aux attaques automatisées les plus basiques. C’est une mesure d’hygiène, pas un blindage.

Et si tu installes WordPress via Composer ou une stack headless, le préfixe fait partie du template de configuration que tu versionnes avec le reste. Une variable de plus dans ton fichier .env, rien de plus. Les outils modernes d’édition de code t’accompagnent bien sur ce genre de refactoring global ; d’ailleurs, sur des projets plus lourds en JavaScript, le choix entre Claude Code et Cursor IDE se joue beaucoup sur cette capacité à modifier du code à l’échelle du projet sans introduire d’erreurs silencieuses.

Quand le préfixe change et que le state management de l’admin part en vrille

Un symptôme moins connu du changement de préfixe, c’est la corruption silencieuse des options sérialisées dans la table wp_options. Certaines extensions stockent des objets PHP sérialisés qui contiennent des noms de tables complets. Si l’option mon_extension_config stocke a:2:{s:5:"table";s:13:"wp_mes_donnees";...}, le changement de préfixe laisse une chaîne obsolète dans la base.

Résultat : l’extension ne trouve plus sa table, et selon la robustesse de son code, soit elle recrée une table vide avec l’ancien nom (doublon inutile), soit elle échoue en silence avec des fonctionnalités manquantes.

C’est le même type de problème qu’un state manager qui se désynchronise : l’état stocké ne correspond plus à la réalité de l’application, et rien ne le signale explicitement. En React, on résout ça avec un selector normalisé et un reducer qui valide le schéma. Avec Zustand, c’est encore plus direct parce que le store est un objet plat et prévisible, mais la comparaison s’arrête là. En base de données, tu n’as pas de hot reload : tu as des données persistantes à corriger manuellement.

La parade : un wp search-replace qui couvre toutes les tables, pas seulement wp_posts et wp_postmeta, avec le flag --dry-run d’abord pour estimer le nombre d’occurrences. Puis tu examines les résultats qui concernent des options, une par une si nécessaire. Une approche différente de celle qu’on adopte pour le state management React avec Zustand, où la prédictibilité du flux de données rend ce type d’incohérence quasiment impossible par construction.

Questions fréquentes

Est-ce que Google pénalise un site WordPress avec le préfixe wp_ par défaut ?

Aucun signal de classement ne prend en compte le préfixe des tables. Googlebot ne voit pas ta structure de base de données. Ce qui intéresse les moteurs, c’est le contenu servi, le temps de réponse, et la présence éventuelle de contenus piratés. Le préfixe est invisible côté client.

Peut-on changer le préfixe sur un multisite WordPress ?

Oui, mais chaque site du réseau a ses propres tables avec un préfixe incrémenté (wp_2_posts, wp_3_options). La manipulation doit renommer toutes les tables de tous les sites, plus les tables globales (wp_blogs, wp_site, etc.). WP-CLI le gère avec wp db prefix exécuté pour chaque blog_id. Sans WP-CLI, c’est une opération risquée que je déconseille sur un multisite en production.

Faut-il changer le préfixe après avoir été piraté ?

Changer le préfixe après une compromission ne nettoie rien. Les backdoors ne sont pas dans les noms de tables, elles sont dans les fichiers PHP, dans les entrées de la base, ou dans les comptes utilisateurs ajoutés. La procédure post-piratage, c’est une restauration complète depuis un backup propre, une réinitialisation de tous les mots de passe, et un audit du système de fichiers. Le préfixe peut changer dans la foulée, mais ce n’est pas la priorité.