Connecter une boutique PrestaShop à un ERP, un outil de stock, un CRM ou une solution logistique passe souvent par le webservice natif. L’API permet de lire et de modifier des ressources comme les produits, les clients ou les commandes, sans intervenir directement dans la base de données.

Le risque commence lorsqu’on traite la clé d’API comme un simple paramètre de configuration. Dans PrestaShop, cette clé donne accès aux ressources et aux méthodes qui lui ont été attribuées. Une clé trop permissive, copiée dans un dépôt Git ou placée dans une URL peut donc transformer une intégration pratique en point d’entrée très sensible.

Voici une méthode concrète pour préparer une intégration PrestaShop plus propre : définir son périmètre, limiter les permissions, protéger la clé, réduire les données échangées et vérifier les erreurs avant la mise en production.

Commencer par définir ce que l’intégration doit vraiment faire

Avant de créer une clé, il faut décrire le flux avec des verbes simples. L’outil externe doit-il uniquement lire les références et les stocks ? Doit-il créer des commandes ? Mettre à jour les prix ? Synchroniser les clients ? Plusieurs réponses signifient généralement plusieurs flux, et pas forcément une seule clé commune.

Prenons un exemple hypothétique : un logiciel de gestion récupère les commandes toutes les quinze minutes et renvoie ensuite les numéros de suivi. Il lui faut probablement un accès en lecture sur les commandes et un accès limité sur les informations d’expédition. Il n’a aucune raison de pouvoir supprimer des produits, modifier les clients ou lire la configuration générale de la boutique.

Cette étape paraît évidente, mais elle évite un réflexe fréquent : cocher toutes les cases parce que l’intégration n’est pas encore parfaitement définie. Une permission accordée “pour tester” finit souvent par rester active pendant des années.

Comprendre les droits du webservice PrestaShop

Le webservice PrestaShop est accessible via le chemin /api/ à la racine de l’installation. Les ressources disponibles sont exposées sous ce point d’entrée : par exemple /api/products, /api/orders ou /api/customers.

Dans le back-office, une clé de webservice est associée à des permissions. Celles-ci sont définies par ressource et par méthode HTTP. On peut ainsi autoriser la lecture d’une ressource sans autoriser sa modification, ou réserver les opérations d’écriture aux seules ressources réellement nécessaires.

La différence entre ces méthodes est importante :

• GET sert à lire ;
• POST sert généralement à créer ;
• PUT sert à remplacer ou mettre à jour une ressource ;
• PATCH permet une mise à jour partielle ;
• DELETE supprime une ressource.

Une intégration qui ne fait que consulter des produits devrait donc rester limitée à la lecture. Accorder POST, PUT, PATCH et DELETE “au cas où” augmente fortement le risque d’erreur ou d’utilisation abusive.

En multiboutique, la boutique ou le groupe de boutiques associé à la clé doit également être vérifié. Une synchronisation prévue pour un seul catalogue ne devrait pas obtenir automatiquement une portée sur toutes les boutiques.

Créer une clé par usage, pas une clé pour toute l’entreprise

Une seule clé partagée entre l’ERP, le transporteur, le CRM et un script d’import est difficile à auditer. Si elle fuite, il faut interrompre plusieurs flux en même temps. Si une personne quitte le projet, il est également compliqué de savoir ce qu’il faut révoquer.

Une approche plus saine consiste à créer une clé par intégration ou par famille de flux :

• une clé en lecture seule pour le catalogue ;
• une clé dédiée à la remontée des commandes ;
• une clé séparée pour la mise à jour des stocks ;
• une clé temporaire pour un diagnostic ou une migration.

Le nom et la description de la clé doivent expliquer son propriétaire, son objectif et la date de sa dernière vérification. La description ne protège pas techniquement la clé, mais elle réduit les accès oubliés dans un back-office qui a vécu plusieurs années.

Lorsqu’une intégration n’est plus utilisée, désactivez sa clé. Pour une rotation, créez la nouvelle clé, déployez-la, testez le flux, puis désactivez l’ancienne. Cette séquence limite le risque de coupure et évite de modifier un secret critique directement dans plusieurs systèmes à la fois.

Ne placez pas la clé PrestaShop dans l’URL

La documentation PrestaShop présente encore l’authentification par clé dans l’URL comme une possibilité de test, mais la déconseille pour une boutique en production. Une clé présente dans l’URL peut se retrouver dans l’historique du navigateur, des journaux HTTP, des outils de supervision, un proxy ou une capture de requête.

Utilisez plutôt l’en-tête Authorization. Le webservice PrestaShop attend une authentification HTTP Basic dont le nom d’utilisateur est la clé et dont le mot de passe est vide. L’en-tête contient une valeur encodée en Base64 ; cet encodage n’est pas un chiffrement. Il faut donc impérativement utiliser HTTPS.

Exemple de test avec une variable d’environnement, à adapter à votre environnement :

curl --fail --silent --show-error \
  --user "${PRESTASHOP_API_KEY}" \
  --header "Output-Format: JSON" \
  "https://boutique.example/api/products?display=[id,reference,active]&limit=0,20";

La variable PRESTASHOP_API_KEY ne doit pas être commitée dans le dépôt. Utilisez le gestionnaire de secrets de l’hébergement, les variables protégées de la CI ou un fichier local exclu du versionnement. Vérifiez aussi que les logs ne recopient pas l’en-tête d’authentification ou l’URL complète.

Réduire les données retournées par l’API

Limiter les permissions ne suffit pas toujours. Une intégration peut avoir le droit de lire une ressource tout en récupérant beaucoup plus de champs que nécessaire.

Le paramètre display permet de demander un sous-ensemble de champs lors de certaines lectures. Si un outil doit seulement connaître l’identifiant, la référence et l’état actif d’un produit, il n’a pas besoin de charger toute sa description, ses associations ou ses autres informations internes.

Cette réduction apporte trois bénéfices :

• moins de données sensibles qui circulent ;
• des réponses plus légères et plus faciles à traiter ;
• moins de dépendance de l’intégration à la structure complète de la ressource.

Il faut toutefois garder une limite en tête : le paramétrage display n’est pas un remplacement des permissions. Il contrôle la réponse demandée par le client, mais ne crée pas une politique métier complète au niveau de chaque champ. Si un tiers doit recevoir un format très précis, créez plutôt une couche intermédiaire qui sélectionne et transforme les données avant de les transmettre.

Ne confondez pas sortie JSON et API JSON complète

Le webservice PrestaShop peut produire du JSON en utilisant le paramètre output_format=JSON, io_format=JSON ou un en-tête équivalent. C’est pratique lorsqu’une application consomme déjà ce format.

La documentation actuelle de PrestaShop précise cependant que, depuis PrestaShop 8.1, le webservice natif peut produire du JSON mais ne lit pas les entrées JSON. Les opérations d’écriture restent donc à prévoir avec le format accepté par l’endpoint, généralement le XML du webservice historique.

Ce détail doit être vérifié avant de choisir une bibliothèque ou de promettre une intégration “100 % JSON”. Une lecture qui fonctionne avec un en-tête JSON ne prouve pas qu’un POST, un PUT ou un PATCH acceptera le même format.

Tester les permissions avec des scénarios négatifs

Un test réussi ne montre qu’une chose : l’appel testé est autorisé. Pour vérifier la sécurité d’une clé, il faut aussi tester ce qu’elle doit refuser.

Pour chaque intégration, préparez une petite matrice :

• lecture d’une ressource autorisée ;
• lecture d’une ressource non nécessaire ;
• tentative de modification d’une ressource en lecture seule ;
• tentative d’accès à une autre boutique en multiboutique ;
• appel sans clé, avec une clé désactivée et avec une clé erronée.

Les erreurs d’authentification et d’autorisation doivent être distinguées dans les logs internes, sans enregistrer la clé elle-même. Une réponse inattendue ne doit pas être “corrigée” en donnant tous les droits à la clé. Il faut d’abord vérifier la ressource, la méthode HTTP, l’URL, le format envoyé et la configuration du serveur.

Sur Apache, si l’en-tête Authorization n’arrive pas jusqu’à PrestaShop, la directive CGIPassAuth On ou une transmission équivalente peut être nécessaire selon l’hébergement. Ce réglage dépend de l’infrastructure : il se vérifie dans la configuration du serveur et non dans le code de l’intégration.

Ajouter une couche intermédiaire pour les flux sensibles

Le webservice natif est utile, mais il ne doit pas forcément être exposé directement à tous les systèmes externes. Une couche intermédiaire peut stocker le secret, appliquer des règles métier, limiter le rythme des appels, transformer les données et centraliser les logs.

Cette architecture est particulièrement pertinente lorsque l’intégration doit :

• exposer seulement quelques champs d’une commande ;
• valider une transition d’état avant de l’envoyer à PrestaShop ;
• éviter qu’un outil tiers puisse appeler directement des ressources sensibles ;
• réessayer un appel sans créer deux fois la même commande ;
• surveiller les erreurs et prévenir quelqu’un en cas de rupture.

Il ne s’agit pas de construire une architecture complexe pour chaque boutique. Pour un petit flux interne, une application ou un script correctement isolé peut suffire. L’important est de ne pas laisser une clé très permissive se promener dans plusieurs outils sans propriétaire clair.

La checklist avant la mise en production

Avant d’activer une intégration PrestaShop, vérifiez au minimum :

• le besoin exact et les ressources réellement utilisées ;
• les méthodes autorisées, avec une préférence pour la lecture seule quand c’est possible ;
• la boutique concernée en cas de multiboutique ;
• l’utilisation de HTTPS et de l’en-tête Authorization ;
• l’absence de clé dans le dépôt, l’URL, les captures et les logs ;
• la rotation et la révocation prévues ;
• les tests positifs et négatifs ;
• la surveillance des erreurs et des appels anormaux ;
• la documentation du flux et de son responsable.

Pour une boutique qui doit connecter plusieurs outils, un accompagnement PrestaShop peut aider à remettre à plat les accès, les modules et la configuration serveur. Lorsqu’un flux métier sort du cadre du webservice standard, une intégration API sur mesure permet aussi de garder une séparation plus nette entre la boutique et les services tiers.

À retenir

Une clé PrestaShop n’est pas un mot de passe anodin. Elle peut donner accès à des données clients, des commandes, des prix ou des stocks, et certaines permissions permettent de modifier ou supprimer des ressources.

La sécurité d’une intégration repose donc sur plusieurs décisions simples : une clé par usage, le moins de droits possible, aucun secret dans l’URL, HTTPS partout, des données limitées et des tests qui vérifient aussi les refus. Si une intégration a besoin de droits très larges pour fonctionner, c’est souvent le signe qu’il faut revoir son périmètre ou ajouter une couche intermédiaire.

Sources

• Documentation PrestaShop 9 – Getting Started du webservice
• Documentation PrestaShop 9 – Testing access to the Webservice
• OWASP API Security Top 10 – édition 2023

Thomas Pecriaux

Black Sheep Code

23 articles publishedExpertise: Wordpress, SEO, Prestashop, PHP Development

linkedin.com