Clé webservice PrestaShop encore active
Paramètres avancés → webservice : une clé « test » de l’intégrateur, permissions trop larges. Après incident on révoque, même si « on s’en sert pour le stock ». On en recrée une propre, minimale, documentée.
Advanced Parameters > Webservice. Une clé « test » de l'intégrateur. Permissions trop larges. Révoquez après incident, même si « on s'en sert pour le stock » : recréez-en une propre.
Ce qu’une clé webservice ouvre
Le webservice PrestaShop (API) s’authentifie par une clé. Selon les ressources cochées : produits, commandes, clients, stocks, parfois plus. C’est le cousin des clés Woo. Un ERP, un WMS, un outil de veille prix, un « connecteur Amazon » : chacun a pu en avoir une.
Une clé « test » de 2019 avec toutes les ressources en GET+PUT est un admin parallèle. Changer le mot de passe du back-office ne la touche pas.
Après un PrestaShop piraté, cet écran fait partie du constat, au même titre que les employés et les modules.
L’écran qu’on n’ouvre jamais
Paramètres avancés → webservice : activer le webservice (oui/non), liste des clés, CGI, etc. Beaucoup de boutiques l’ont activé « le temps de l’intégration » et laissé. Désactiver le webservice entier casse le stock du matin : d’où la peur, d’où l’oubli, d’où la clé éternelle.
On ne désactive pas à l’aveugle le dimanche soir si la logistique tourne lundi. On liste, on révoque l’inconnu, on tourne les clés nommées avec le prestataire dans la semaine. L’inconnu, lui, n’attend pas lundi. Un entrepôt qui ne peut plus pousser les stocks à 5 h est un argument pour planifier la rotation, pas pour laisser la clé « test » vivante jusqu’à jeudi.
Versions 1.6 / 1.7 / 8 : l’écran bouge peu. Les 1.6/1.7 obsolètes sont un autre risque (cœur). Ici : la clé, même sur un 8 à jour.
Permissions : le défaut des prestataires
Cocher toutes les ressources « pour que ça marche » est le standard des recettes. Après incident : une clé = un usage (stock GET/PUT products + stock_availables, pas customers). Recréez. L’intégrateur râle une heure, la surface baisse pour des années. Si personne ne sait à quoi sert une clé, elle n’a pas d’usage : suppression, pas « on verra au cas où le WMS la reprend ».
Les méthodes (GET, POST, PUT, DELETE) se lisent par ressource. DELETE sur customers n’a rien à faire d’un sync stock.
Plusieurs clés identiques « au cas où » : n’en gardez une par outil. La révocation devient possible sans tout casser.
- Nommer la clé avec l’outil et l’année.
- Cocher le minimum, tester le flux, ajouter une ressource si échec.
- Pas de clé partagée entre deux prestataires.
Révoquer et recréer sans tuer la logistique
Inconnu : suppression immédiate. Métier : créneau avec le WMS (15 minutes), nouvelle clé, màj de leur côté, suppression de l’ancienne. Un fichier de config chez eux contient l’ancienne : ils doivent la remplacer, pas vous « espérer ».
Si le prestataire a disparu : révoquez, le flux meurt, vous avez trouvé un flux fantôme. Recâblez plus tard.
Copie boutique + base avant. Une fausse manip sur les permissions n’est pas une restauration du catalogue.
Où la clé a été copiée
Email à l’intégrateur, wiki Confluence, .env d’un script sur un PC, module custom dans /modules. Après vol d’admin, considérez les copies compromises. Tournez même les clés « qu’on utilise vraiment ».
Un module « webservice helper » peut afficher la clé en clair dans le BO à un employé trop large. Réduisez les profils employés.
Git : même règle que Woo. Révoquez si le dépôt a pu fuir.
Webservice vs employé vs FTP
Trois accès. L’employé back-office, le FTP/SFTP, la clé. Changer l’un laisse les autres. Mot de passe panel d’abord (premiers gestes).
Un employé « webservice » créé par Presta pour l’API : regardez-le, désactivez-le s’il est admin déguisé.
Le guide PrestaShop : modules, overrides, .htaccess. La clé est la ligne API de cette checklist.
Journaux et boutique encore sale
Les accès webservice apparaissent dans les logs serveur (`/api/`). Demandez-les à l’hébergeur. Absence de log ≠ innocence. Un pic d’appels GET /customers la nuit de l’intrusion, même sans certitude d’exfiltration, entre dans le constat fuite : dates, ressource, clé concernée. Vous n’avez pas besoin du contenu des réponses pour commencer à dater.
Si un skimmer tournait, l’API n’est pas le seul canal. PSP, constat, éventuellement CNIL — obligations.
Ne rouvrez pas le webservice large « le temps que le site soit propre ». C’est pendant l’instabilité que les exports arrivent.
Refermer PrestaShop autour de l’API
Webservice activé seulement si un flux le justifie. IP allowlist côté WMS si l’hébergeur le permet (pas toujours en mutualisé). HTTPS obligatoire. Clés tournées, documentées.
J+30 : écran encore aligné avec la liste écrite. Une clé nouvelle sans ticket = non.
Créer un espace si trois connecteurs et un 1.6. On cartographie les clés. Guide Presta pour le reste du CMS.