Un partenaire logistique, une marketplace, un cabinet comptable qui veut synchroniser ses factures : les demandes d’accès à l’API REST WooCommerce arrivent régulièrement, et elles se ressemblent presque toujours dans leur urgence — « il nous faut la clé pour vendredi ». C’est précisément dans cette urgence que se glissent les erreurs de configuration qui, des mois plus tard, se transforment en incidents de sécurité.
Cette checklist ne couvre pas la génération d’une clé et son authentification technique de base (déjà traitée ailleurs), mais tout ce qu’il faut vérifier en amont et en aval de cette étape, pour qu’un accès partenaire reste un accès maîtrisé plutôt qu’une porte ouverte oubliée.
Avant de générer la clé
- Lister précisément les ressources nécessaires. Un partenaire logistique a besoin des commandes et de leur statut d’expédition, pas des données clients complètes ni du détail des remises appliquées. Documenter ce périmètre avant de créer la clé évite de devoir la révoquer et la régénérer une semaine plus tard.
- Choisir le niveau de permission le plus bas possible. WooCommerce propose trois niveaux : lecture, écriture, lecture/écriture. Une synchronisation de statut de commande n’a besoin que d’écriture ciblée sur un sous-ensemble de champs, jamais d’un accès lecture/écriture générique à toute l’API.
- Créer un utilisateur WordPress dédié au partenaire, distinct de tout compte administrateur existant, avec un rôle spécifique si l’accès doit être restreint à certains points de terminaison seulement — ce qui suppose souvent un plugin de gestion fine des capacités ou un développement sur mesure au-dessus des rôles WordPress natifs.
- Vérifier que le site est exclusivement servi en HTTPS, y compris sur les environnements de préproduction utilisés pour les tests d’intégration du partenaire — une clé API transmise en clair sur HTTP est une clé déjà compromise.
Pendant la mise en place
- Activer un journal d’accès dédié à cette clé avant même la première requête réelle du partenaire, pas après un premier incident.
- Documenter, côté partenaire et côté agence, l’adresse IP ou la plage d’adresses depuis laquelle les appels sont attendus, pour permettre un filtrage complémentaire au niveau du pare-feu applicatif si l’infrastructure le permet.
- Tester les points de terminaison exposés avec des identifiants de test, jamais avec les clés définitives, pour vérifier qu’aucune ressource non prévue n’est accessible avec le niveau de permission choisi.
- Vérifier la présence d’une limite de débit (rate limiting) au niveau du serveur ou d’un plugin dédié, pour qu’un dysfonctionnement côté partenaire ne se traduise pas par une boutique saturée de requêtes.
Ce que le journal d’accès doit contenir
Un simple journal serveur ne suffit généralement pas : il faut pouvoir répondre, en cas d’incident, à la question « quelles données précises ce partenaire a-t-il consultées, et quand ». Un enregistrement minimal comprend l’identifiant de la clé utilisée, le point de terminaison appelé, l’horodatage, et le code de réponse retourné. Ce niveau de détail permet, des mois après la mise en place, de distinguer un usage normal d’un usage anormal sans devoir reconstituer l’historique à partir de rien.
Une fois l’accès en production
- Planifier une date de revue de l’accès, même en l’absence d’incident — six mois est une fréquence raisonnable pour un partenariat actif.
- Vérifier périodiquement que le périmètre de données réellement consulté correspond toujours au périmètre initialement documenté : un partenaire qui ajoute discrètement de nouveaux appels doit être identifié.
- Prévoir la procédure de révocation avant d’en avoir besoin : qui a le pouvoir de révoquer la clé en urgence, et combien de temps cela prend-il réellement une fois la décision prise.
Le piège de la clé qu’on oublie
Le risque le plus fréquent n’est pas la faille technique, c’est l’oubli. Un partenariat qui se termine, un prestataire qui change d’outil de synchronisation : la clé API, elle, continue d’exister tant que personne ne pense à la révoquer explicitement dans le tableau de bord WooCommerce. Une clé API qui n’a servi à aucune requête depuis plusieurs mois doit être considérée comme un candidat automatique à la révocation, pas comme un détail administratif sans conséquence.
La question à se poser n’est jamais « cette clé fonctionne-t-elle encore » mais « quelqu’un se souvient-il encore pourquoi elle existe ». Si la réponse est non, il est temps de la révoquer.
Checklist récapitulative
- Ressources et champs strictement nécessaires listés avant génération de la clé.
- Niveau de permission le plus restrictif compatible avec l’usage prévu.
- Compte dédié, jamais de compte administrateur partagé.
- HTTPS obligatoire sur tous les environnements, y compris de test.
- Journal d’accès actif avant la première requête réelle.
- Limite de débit vérifiée côté serveur.
- Date de revue planifiée dès la mise en service.
- Procédure de révocation documentée et testée.
En résumé
Ouvrir l’API REST WooCommerce à un partenaire n’est jamais un acte anodin : c’est étendre la surface d’attaque de la boutique à un système que l’on ne contrôle pas. Une checklist appliquée avant, pendant et après la mise en place transforme cette ouverture d’un risque diffus en un accès documenté, limité et réversible.
