Clés REST WooCommerce oubliées dans un plugin ou un Zapier
Une clé REST WooCommerce lit les commandes, parfois écrit le catalogue. Oubliée dans un plugin, un Zapier, un gist. Après incident on révoque, on tourne, on regarde les webhooks. Un Zap abandonné vaut un employé fantôme.
Lecture des commandes, parfois écriture. Révoquez, tournez, regardez les webhooks. Un Zap abandonné vaut un employé fantôme.
Ce que permet une clé REST boutique
WooCommerce → Réglages → Avancé → REST API : consommateur + secret, avec un périmètre (lecture, écriture) et des ressources (commandes, produits, clients). Lecture commandes = historique, emails, adresses, parfois des métadonnées de paiement (pas forcément le PAN — déjà trop). Écriture = prix, stocks, création de commandes fantômes.
Ce n’est pas le mot de passe wp-admin. Un user WordPress y est associé. Révoquer la clé ne change pas ce user ; supprimer le user peut casser la clé. On traite les deux.
Après un piratage, toute clé que vous ne pouvez pas nommer (outil, date, responsable) est hostile jusqu’à preuve du contraire. La preuve, c’est un prestataire qui dit « c’est la caisse du magasin » par écrit, pas un souvenir.
Où elles traînent (hors de l’écran Woo)
wp-config, .env, un plugin « sync stock » custom, un snippet dans le thème, un ticket d’agence, un channel Slack, un Zap en clair, un dépôt Git public. Le panel Woo n’est pas la seule copie. Tourner la clé sans chercher les copies, c’est la laisser vivre ailleurs.
Les sauvegardes Updraft / les zips de migration contiennent parfois le wp-config. Un zip public, c’est une clé publique. Voir le réflexe archives exposées — ici, révoquez dès que le zip a pu fuir, même « le temps d’un transfert ».
Un prestataire de compta ou de PIM qui a demandé « lecture commandes » en 2021 et n’est plus payé : clé encore là. C’est le Zap abandonné en version humaine.
Lister et lire les permissions
Écran REST API : description, user, permissions, dernières ? (selon versions). Capture avant révocation. Les permissions « lecture/écriture » sur tout sont le défaut dangereux des tutos.
Les clés « webhook » et les clés « REST » se ressemblent pour un non-technicien. Onglets séparés. Les webhooks ont des URLs de callback : si l’URL n’est pas à vous, c’est une copie des événements vers un tiers.
WP-CLI `wc` si vous l’avez, sur votre boutique, après copie. Pas d’appel d’essai contre une boutique tierce. Pas de PoC.
- Toutes les clés, y compris « test » et « local ».
- Le user WordPress associé (encore admin ?).
- Lecture vs écriture, ressources.
Révoquer, recréer, moindre privilège
Révoquez l’inconnu tout de suite. Les clés métier : tournez (nouvelle paire, màj du prestataire, révocation de l’ancienne). Un créneau où le stock ne se synchronise pas vaut mieux qu’une écriture hostile.
Recréez avec le user le moins privilégié possible (un compte « api-stock » boutique manager, pas administrateur). Documentez le secret hors du thème.
Si la boutique a pu servir un skimmer, la clé API n’est qu’un chapitre. Paiement : obligations et le prestataire (Stripe, etc.).
Webhooks : l’autre copie des commandes
WooCommerce → Avancé → Webhooks : delivery URL. Une URL inconnue = un tiers reçoit order.created. Désactivez, notez, recréez les vôtres (logistique, compta) après.
Les webhooks échoués en boucle (logs) peuvent saturer. Pendant l’incident, pause. Ce n’est pas un nettoyage de fichiers, c’est une fuite continue de données de commande.
Un webhook vers un Make/Zapier dont le scénario a été modifié par quelqu’un qui avait le compte Make : même famille. Vérifiez le compte Make (2FA, users).
Zapier, Make, caisses, marketplaces
Chaque connecteur a sa copie de la clé ou un OAuth. Après rotation Woo, mettez à jour ou le connecteur crie — bon signal. Les marketplaces (Amazon, Fnac) ont leurs propres tokens : autre liste, même jour si l’admin WP était ouvert.
Une caisse physique (plugin POS) avec une clé write : prioritaire. Un affichage catalogue read-only : moins urgent, quand même tourné si l’admin a fuité.
GTM / pixels : parfois un tag a été ajouté par l’attaquant. Pas une clé REST, mais le même après-midi « qui parle à l’extérieur ». Voir les articles pixel / GTM du site si besoin.
Journaux et ce qu’une clé ne dit pas
Woo ne garde pas toujours un audit complet des appels REST. Les logs serveur (POST /wp-json/wc/) aident si le proxy logue l’URI. Absence de log ≠ absence d’usage.
Ne promettez pas « aucune commande lue » sans constat. RGPD : le guide fuite si des clients sont en jeu. Vous déclarez, pas le prestataire à votre place.
Une clé read-only volée est déjà une lecture possible. Tournez, documentez les dates, parlez au PSP si le checkout était aussi compromis.
Le même jour que les autres secrets
Panel, CMS, application passwords, clés Woo, webhooks, SMTP, Stripe restricted keys, Search Console. Une checklist écrite. Le guide WordPress pour les fichiers ; cet article pour l’API boutique.
Premiers gestes : copie avant de tout révoquer (preuves). Créer un espace si vous ne savez pas ce qui est encore branché (trois zaps, deux caisses, un PIM).
Trente jours : nouvel écran REST, aucun inconnu. Un prestataire qui redemande une clé write « comme avant » : non, moindre privilège.