WooCommerce : tables commandes injectées, HPOS ou pas
Des commandes fantômes ou des meta sales, HPOS ou pas. Exportez, identifiez l'entrée (REST, webhook, employé). Restaurer une vieille table de commandes perd le CA récent — et ramène parfois l'injection.
Des commandes fantômes ou des meta sales. Exportez, identifiez l'entrée (REST, webhook, employé). Restaurer une vieille table de commandes perd le CA récent.
Ce que vous voyez dans WooCommerce
Commandes à 0 €, emails jetables, adresses incohérentes, statuts qui basculent seuls, notes internes en anglais machine, des milliers de clients créés la même nuit. Ou, plus discret : une meta `_payment` qui n'est pas la vôtre, un script dans un champ « custom », un webhook qui pointe ailleurs.
Ce n'est pas toujours un skimmer de checkout. Parfois c'est un test que l'attaquant a la main. Parfois un spam SEO déguisé en produit. Parfois une API ouverte. On exporte avant de supprimer : ces lignes datent l'entrée et nourrissent le constat. Commandes fantômes.
La home peut être impeccable. Le tunnel, non. Testez comme un client. Lisez le HTML de la page paiement. Skimmer JS WooCommerce.
HPOS change le tiroir, pas le diagnostic
High-Performance Order Storage range les commandes dans des tables dédiées plutôt que dans `wp_posts` / `wp_postmeta`. Si HPOS est actif, une restauration « on remet les posts d'il y a trois semaines » rate le tiroir réel — ou le mélange. Si HPOS n'est pas actif, l'injection peut vivre dans les metas de posts `shop_order`.
Le diagnostic ne commence pas par « on coupe HPOS pour simplifier ». Il commence par : où sont les commandes aujourd'hui, quelle sauvegarde les contient, quelle date est encore saine. Basculer HPOS pendant l'incident est une migration au milieu d'un incendie.
Les outils d'export Woo (et HPOS) doivent servir à figer, pas à « réparer en écrasant ». Un CSV du jour J vaut mieux qu'une table d'il y a un mois collée par-dessus le CA de la semaine.
Ne pas restaurer les commandes à l'aveugle
La dernière sauvegarde Updraft contient souvent déjà les commandes fantômes — et le plugin qui les crée. Remonter trop loin perd les vraies ventes. Remonter trop près ramène l'injection. On copie l'état actuel, on compare, on retire les lignes identifiées, on ne jette pas le trimestre.
Restaurer uniquement `wp_posts` sur un site HPOS laisse un Frankenstein. Restaurer les tables HPOS sans les fichiers, c'est remettre des commandes sur un CMS encore ouvert. Les deux se font après fermeture de l'entrée, ou pas du tout si un export ciblé suffit.
Sauvegarde Updraft infectée : ouvrez l'archive, ne la poussez pas en prod par réflexe.
Trouver l'entrée : REST, webhook, humain
L'API REST Woo avec une clé trop large crée des commandes et des clients sans passer par le checkout. Relisez les clés, les permissions `read_write`, les IP. Révoquez les inconnues. Clés REST en clair.
Les webhooks (commande créée → URL) peuvent pointer vers un tiers, ou un tiers peut pousser vers vous. Auditez la liste. Un champ « URL de notification » mal tenu recoupe le sujet webhook / URL interne — on audite, on ne « teste pas » des URLs internes au hasard.
Un employé, un stagiaire shop manager, un compte `admin` partagé : moins glamour, fréquent. Freelance encore admin. Les journaux Woo et les users WP datent.
- Clés REST : qui, quel droit, dernière utilisation.
- Webhooks : destination, secret, événements.
- Rôles `shop_manager` et au-dessus.
Metas, notes, et le HTML qui voyage
Une meta de commande peut porter un script. Une note client s'affiche parfois dans un mail transactionnel. Un champ checkout custom se retrouve dans l'admin et dans les exports comptables. Relisez un échantillon de commandes récentes, pas seulement les fantômes.
Les produits et variations : descriptions avec iframes, extras JS. Le catalogue est une surface SEO autant qu'une surface boutique. Des milliers d'URL produit générées, c'est aussi du spam d'index.
HPOS ou posts : le principe est le même. On cherche du contenu qui n'a rien à faire dans une commande. On ne « TRUNCATE » pas.
Clients, stocks, et ce qu'on documente
Comptes clients créés en masse : exportez, datez, décidez s'il faut forcer un reset de mot de passe. Ça dépend d'un accès avéré à la table, pas d'une impression. Fuite, forcer les mots de passe.
Stocks et prix modifiés : autre motif, même besoin de copie avant correction. Stocks ou prix.
Le constat boutique : fenêtre de temps, volume de commandes suspectes, clés révoquées, si le HTML du checkout a divergé. C'est ce document que Stripe ou la banque comprennent. Pas « on a nettoyé WordPress ».
Nettoyer sans jeter le trimestre
Identifiez un motif (email, user-agent, source `rest-api`, produit à 0 €). Supprimez ou annulez ce lot, conservez l'export. Recalculez les rapports après, pas avant. Informez la compta : des écritures vont bouger.
Les vrais clients de la fenêtre d'incident : ne les effacez pas « au cas où ». Isolez. Contactez si le constat le justifie, pas par panique de masse.
Refermez l'entrée (clé, webhook, plugin, compte) avant de rouvrir le checkout si vous l'aviez coupé. Une boutique qui encaisse à nouveau avec la même clé REST, c'est le deuxième dossier.
Après : clés, rôles, surveillance
Moins de clés, moins de shop managers, 2FA sur les admins. Webhooks signés, destinations que vous nommez. HPOS : ne le basculez qu'à froid, sur un site déjà fermé, avec une sauvegarde saine hors serveur.
Surveillance : pic de commandes aberrantes, nouvel utilisateur `shop_manager`, nouvelle clé REST. Surveillance.
Vous pouvez déléguer en joignant un export (anonymisé si besoin) des commandes suspectes et la liste des clés. Nous ne restaurerons pas 2024 par-dessus 2026.