Un partenaire logistique qui demande un accès en lecture au catalogue WooCommerce d’une boutique pour synchroniser ses propres systèmes de préparation de commande semble, à première vue, une demande simple : lecture seule, données produit, rien de sensible. Cette impression de simplicité est précisément ce qui pousse à négliger des vérifications qui, en pratique, déterminent si cet accès reste maîtrisé dans la durée ou devient un point aveugle du système.
Cette checklist se concentre exclusivement sur les vérifications de périmètre et de journalisation propres à ce type d’accès partenaire. Elle ne traite pas de la sécurisation générale de l’API REST de WooCommerce — authentification, chiffrement, gestion des clés — déjà couverte en détail dans la catégorie sécurité de ce blog.
1. Définir le périmètre exact des champs exposés
Avant toute création de clé d’API, il faut lister précisément quels champs du catalogue sont réellement nécessaires au partenaire pour sa mission de préparation de commande : référence, quantité disponible, emplacement en entrepôt éventuellement. Un accès qui expose par défaut l’intégralité des champs produit — prix d’achat, marge, coût fournisseur — dépasse largement le besoin fonctionnel réel, sans justification métier.
- Lister les champs strictement nécessaires à la mission du partenaire
- Vérifier qu’aucun champ de coût ou de marge n’est exposé sans nécessité explicite
- Documenter cette liste dans un document partagé entre les deux parties, révisable
2. Restreindre l’accès aux seuls points de terminaison utiles
L’API REST de WooCommerce expose bien plus que le seul catalogue : commandes, clients, rapports de vente. Un accès partenaire logistique n’a besoin que des points de terminaison liés au catalogue et, éventuellement, au statut de stock. Accorder par simplicité un accès complet à l’ensemble de l’API, plutôt que de restreindre précisément aux points de terminaison utiles, multiplie inutilement la surface exposée en cas de compromission de la clé côté partenaire.
GET /wp-json/wc/v3/products
GET /wp-json/wc/v3/products/{id}
Ces deux points de terminaison suffisent, dans la majorité des cas, à couvrir un besoin de synchronisation logistique en lecture seule. Toute extension de ce périmètre doit être justifiée explicitement, pas accordée par défaut.
3. Vérifier que la clé accordée est bien en lecture seule, pas seulement nommée ainsi
Une clé d’API WooCommerce se configure avec un niveau de permission explicite. Il est déjà arrivé, sur des projets audités, qu’une clé nommée « lecture seule » dans sa description ait en réalité été créée avec un niveau de permission « lecture/écriture » par erreur d’inattention lors de sa configuration. Vérifier ce paramètre au moment de la création, puis à intervalle régulier, évite qu’une confusion de nommage ne devienne une faille réelle.
4. Mettre en place une journalisation dédiée aux accès partenaire
La journalisation des appels effectués avec la clé du partenaire ne doit pas se confondre avec les journaux généraux du serveur. Un journal dédié, filtrable par clé d’API, permet de répondre rapidement à une question simple mais essentielle en cas d’incident : quels appels cette clé précise a-t-elle réellement effectués, à quelle fréquence, et sur quels enregistrements.
add_action( 'woocommerce_rest_insert_product', function( $product, $request ) {
// exemple de point d'accroche pour journaliser les accès en écriture, à adapter en lecture
}, 10, 2 );
Pour un accès strictement en lecture, la journalisation se fait généralement au niveau du serveur web ou d’une passerelle API dédiée, en conservant au minimum l’horodatage, le point de terminaison appelé et l’identifiant de la clé utilisée.
5. Fixer une fréquence d’appel raisonnable et surveillée
Sans limite explicite, rien n’empêche une synchronisation mal configurée côté partenaire d’interroger le catalogue toutes les minutes plutôt que toutes les heures, générant une charge inutile sur le serveur de la boutique. Convenir d’une fréquence maximale avec le partenaire, puis la surveiller réellement plutôt que de la supposer respectée, évite ce type de dérive silencieuse.
6. Prévoir la révocation avant même l’ouverture de l’accès
La procédure de révocation d’une clé d’API partenaire doit être définie et testée avant l’ouverture de l’accès, pas improvisée le jour où la relation commerciale prend fin ou où un incident de sécurité est suspecté. Savoir précisément qui, en interne, peut révoquer cette clé en quelques minutes fait partie des vérifications à valider avant, pas après.
7. Revoir périodiquement la nécessité de l’accès
Un accès accordé pour un besoin ponctuel a tendance à rester actif bien après que ce besoin a disparu, simplement parce que personne ne pense à le retirer une fois la mission terminée. Une revue périodique, semestrielle par exemple, de l’ensemble des clés API partenaires actives permet de désactiver celles dont l’usage réel s’est éteint sans révocation formelle.
Un accès en lecture seule reste un accès : il mérite exactement la même rigueur de revue et de journalisation qu’un accès en écriture, simplement pour des raisons différentes.
En résumé
Ouvrir un accès en lecture au catalogue WooCommerce à un partenaire logistique demande une préparation qui dépasse la simple génération d’une clé d’API. Périmètre des champs exposés, restriction des points de terminaison, journalisation dédiée, fréquence surveillée et procédure de révocation déjà prête : ces sept vérifications, traitées avant l’ouverture de l’accès plutôt qu’après un incident, font toute la différence entre un partenariat maîtrisé et un point aveugle du système.
