Les scopes et le principe du moindre privilège
Le guide précédent a introduit l'autorisation. Ce guide vous apprend à la demander avec parcimonie, jamais par réflexe.
Un scope est une permission précise et nommée, que votre application déclare avoir besoin d'utiliser. Chaque action possible sur l'Admin API est rattachée à un scope : lire des produits, modifier des commandes, accéder aux informations clients.
Quelques scopes courants
Remarquez la distinction systématique entre read_ et write_ : lire une donnée et la modifier sont deux permissions séparées, jamais confondues. Une application qui n'a besoin que de consulter des commandes ne devrait jamais demander write_orders.
Où déclarer les scopes d'une application
Les scopes nécessaires à votre application se déclarent dans son fichier de configuration, généralement nommé shopify.app.toml, à la racine du projet généré par Shopify CLI, un fichier que vous découvrirez concrètement au guide 22 de ce parcours. C'est cette liste de scopes que Shopify affichera au marchand au moment de l'installation, pour qu'il sache précisément ce qu'il autorise.
Le principe du moindre privilège
Ce principe, déjà rencontré dans le parcours MCP de Web-Shine Docs à propos des serveurs Gmail et Google Calendar, s'applique exactement de la même façon ici : ne demandez jamais plus de permissions que ce dont votre application a réellement besoin, à cet instant précis de son développement. Une synchronisation de commandes vers un logiciel de comptabilité, l'exemple utilisé au guide 2 de ce parcours, a besoin de read_orders, pas de write_products ni de read_customers, sauf si la comptabilité a explicitement besoin de ces informations clients.
Pourquoi cette rigueur compte vraiment
Une application qui demande trop de permissions inspire moins confiance à un marchand qui les lit avant d'installer, comme vous l'avez appris à le faire vous-même dans plusieurs parcours de Web-Shine Docs face à une demande d'autorisation. Elle représente aussi un risque plus grand en cas de faille de sécurité : si le jeton d'accès de votre application était un jour compromis, l'ampleur des dégâts possibles dépend directement de l'étendue des permissions accordées, pas seulement de celles réellement utilisées par votre code.
Avant d'ajouter un nouveau scope à votre application, posez-vous une question simple : quelle fonctionnalité précise, déjà développée ou sur le point de l'être, a réellement besoin de cette permission ? Si la réponse reste vague ou hypothétique, n'ajoutez pas encore ce scope : vous pourrez toujours l'ajouter plus tard, au moment où le besoin devient réel.
Vérifiez que vous avez compris
Votre application affiche uniquement, dans l'administration, un résumé en lecture seule des dernières commandes d'Atelier Lumière, sans jamais les modifier. Devez-vous demander le scope write_orders en plus de read_orders ?
Non. Puisque votre application ne fait que lire les commandes, sans jamais les modifier, seul read_orders est nécessaire. Demander write_orders en plus, sans besoin réel, contredirait directement le principe du moindre privilège présenté dans ce guide.