Comment tester les autorisations d’une API de fichiers : ressources, actions et cas négatifs

Un guide de planification, pas le contrat d’une API

L’authentification concerne l’identité qui présente une requête ; l’autorisation détermine si cette identité peut effectuer une action. Cette distinction aide à organiser une vérification, mais ne précise pas quelles autorisations, ressources ou réponses une API de fichiers donnée prend en charge.

Considérez les exemples de ce guide comme des pistes de planification, et non comme des comportements vérifiés d’un service. Avant de préparer des cas de test, consultez la documentation de référence et la configuration applicable pour identifier les opérations disponibles, les exigences d’authentification et les critères de résultat.

Les références à des produits précis ne constituent pas des règles universelles. Microsoft présente ApiCenterMinimalPermissionsPlugin comme un outil permettant de vérifier si une application appelle les API avec le minimum d’autorisations ([Microsoft Learn](https://learn.microsoft.com/es-es/microsoft-cloud/dev/dev-proxy/how-to/check-minimal-api-permissions)). Pour Google Drive, la documentation indique qu’il faut déclarer les autorisations nécessaires à l’application dans la configuration de consentement OAuth ([Google for Developers](https://developers.google.com/workspace/drive/api/guides/api-specific-auth?hl=es-419)). Ces références ne définissent pas le fonctionnement d’une autre API.

• Séparez les principes généraux de test des capacités confirmées du service intégré.
• Définissez les résultats attendus à partir de la documentation et de la configuration du produit.
• Ne transposez pas à une autre API les autorisations, les outils ou les flux propres à Microsoft ou à Google.

Définir le périmètre avant de préparer les cas

Commencez par délimiter ce que vous souhaitez valider. Notez les identités de test que vous êtes autorisé à utiliser, les ressources de test disponibles et les opérations mentionnées dans la documentation. L’objectif est de transformer des exigences vérifiables en questions de test concrètes.

Pour chaque opération évaluée, consignez les préconditions pertinentes et la source du critère attendu, par exemple une section de la documentation ou une configuration du service. Si vous ne pouvez pas justifier pourquoi une identité devrait pouvoir effectuer l’action, indiquez que le critère reste à confirmer.

Ne présumez pas que le service définit un fichier appartenant à l’utilisateur ni qu’il organise les accès au moyen de rôles, de groupes ou de liens. Si ces concepts sont documentés, reprenez leurs définitions exactes ; sinon, ne les ajoutez pas au plan.

• Consignez l’identité logique de test, la ressource, l’action et les préconditions.
• Associez chaque résultat attendu à une source vérifiable.
• Signalez les points que la documentation ne précise pas.

Concevoir des cas qui répondent à des questions précises

Associez chaque cas à une question ciblée : quelle exigence vérifie-t-on, quelle condition reste inchangée et quel résultat confirmerait ou réfuterait le critère ? Cette structure aide à interpréter les réponses dans leur contexte.

Lorsque le contrat de l’API décrit différentes opérations, évaluez-les séparément. Le résultat observé pour l’une ne démontre pas automatiquement ce qui se passerait avec une autre. Appuyez les attentes d’autorisation sur un critère documenté.

Pour comparer deux conditions, ne modifiez qu’une variable lorsque la conception de l’API et l’environnement le permettent. Vous pourrez ainsi attribuer plus clairement toute différence observée.

Distinguez les résultats attendus des résultats observés. Si la réponse ne correspond pas à ce que prévoit la documentation, consignez l’écart et la référence consultée.

• Formulez une question vérifiable pour chaque cas.
• Évaluez séparément les opérations et les conditions.
• Consignez les ambiguïtés du contrat comme des questions en suspens.

Exemple sous conditions : tester avec un autre identifiant

Si la documentation décrit des requêtes qui identifient des ressources et que l’environnement permet de les tester, vous pouvez envisager un essai contrôlé avec une autre ressource de test. Vérifiez si le résultat observé correspond au critère défini par la documentation et la configuration. Cet exemple ne présuppose pas que toutes les API utilisent des identifiants ou partagent le même comportement d’autorisation.

Avant l’essai, confirmez que vous y êtes autorisé et que les ressources sont adaptées aux tests. Définissez les informations à observer et évitez toute modification qui ne fait pas partie du cas. Si l’opération peut modifier du contenu, vérifiez ensuite l’état de la ressource au moyen d’une méthode autorisée par le service et ne consignez que les éléments nécessaires.

N’utilisez pas l’identifiant d’une autre personne ni des données privées à la place d’un environnement de test. Si le comportement attendu n’est pas décrit, consignez la question et demandez des précisions plutôt que d’interpréter une réponse générique comme la preuve d’une politique précise.

• Effectuez l’essai uniquement avec des identifiants et des ressources autorisés.
• N’utilisez des identifiants de test que si l’API et l’environnement permettent ce type de vérification.
• Comparez les observations au critère documenté.

Consigner des résultats qu’une autre personne peut examiner

Pour chaque cas, conservez la date, l’identité logique de test, la ressource, l’action, les préconditions, les résultats attendus et observés, ainsi que la référence documentaire qui justifie le critère.

Avant de partager des requêtes, des réponses ou des captures d’écran, masquez les identifiants, les jetons et les autres secrets. Évitez aussi d’inclure des informations privées qui ne sont pas nécessaires pour expliquer le résultat ; un extrait expurgé peut suffire.

Séparez les faits observés des interprétations. Si la documentation ne permet pas de trancher un écart, signalez-le comme une question en suspens et adressez-la au fournisseur ou au responsable technique.

• Indiquez le critère et sa source avec le résultat de chaque cas.
• Limitez les éléments de preuve à ce qui est nécessaire à l’examen.
• Distinguez les observations, les conclusions et les questions sans réponse.

Relier la vérification aux capacités d’Apification

Le catalogue d’Apification indique que Cloud permet de protéger des fichiers et des services au moyen d’autorisations, d’OTP, d’une authentification externe, de restrictions et de fenêtres de publication. Il décrit également le partage au moyen de liens, d’utilisateurs ou de groupes. Ces capacités peuvent orienter l’examen d’une configuration Cloud, mais ne définissent pas à elles seules un modèle d’autorisation pour une API ni le résultat d’une requête donnée.

Le catalogue indique aussi que Cloud et ses services peuvent être intégrés au moyen d’API REST, d’OpenAPI, de webhooks, d’iframe et de JavaScript. Il s’agit d’options d’intégration décrites au niveau du produit, et non de détails sur des endpoints, des paramètres ou des résultats attendus. Consultez la documentation applicable pour concevoir des tests visant un service précis.

Dans vos conclusions, distinguez les capacités confirmées par le catalogue des détails d’autorisation qui restent à vérifier.

• Utilisez le catalogue pour repérer les capacités du produit, sans en déduire des détails sur les endpoints.
• Consultez la documentation spécifique avant de transformer une capacité en cas d’intégration.
• Indiquez les détails d’autorisation qui n’ont pas encore été vérifiés.

Terminer la vérification par une liste de contrôle

Avant d’intégrer le service ou de partager les résultats, vérifiez que le périmètre est compréhensible et que les critères sont étayés. Si un test ne peut pas être effectué avec autorisation ou si son résultat attendu ne peut pas être justifié, ne le présentez pas comme une vérification concluante.

Cette liste aide à repérer les suppositions et les éléments de preuve incomplets ; elle ne remplace pas la documentation du service et ne garantit pas un résultat de sécurité.

• Chaque opération évaluée est-elle décrite pour l’API concernée ?
• Les résultats attendus reposent-ils sur une documentation ou une configuration vérifiable ?
• Les résultats observés sont-ils distingués des conclusions ?
• Les tests se limitent-ils aux ressources et aux identifiants autorisés ?
• Les secrets et les données privées ont-ils été supprimés des éléments de preuve ?
• Les questions en suspens sont-elles signalées plutôt que tranchées par des suppositions ?

Questions fréquentes