Comment tester l’autorisation des objets API entre différents locataires ?

Je teste l’autorisation des objets API en comparant les requêtes à un modèle d’autorisation explicite, à l’aide de comptes et d’objets contrôlés de part et d’autre de chaque limite. Un refus valide doit exclure les données protégées de la réponse et empêcher les effets interdits, tandis qu’une requête autorisée correspondant au modèle doit continuer de fonctionner. Le test doit également couvrir les modifications d’autorisations, les chemins d’accès alternatifs et les tâches différées. Un jeton valide ou un bouton d’interface masqué ne permet pas de garantir ces propriétés.

La question difficile est de savoir ce que prouve réellement un test réussi. Une API peut rejeter l’identifiant d’un objet étranger dans un gestionnaire tout en laissant passer ce même objet via une exportation, en acceptant la mise à jour d’un champ interdit ou en autorisant une tâche en file d’attente avec les droits d’accès de la veille. Je propose une méthode permettant de vérifier ces affirmations. Elle combine des normes de référence, des recommandations d’évaluation et une conception publiée de système d’autorisation ; l’exemple présenté est hypothétique et ne constitue pas une affirmation concernant un déploiement chez un client ni un taux de vulnérabilité mesuré.

Commencez par la décision métier que le serveur doit mettre en œuvre

Avant de sélectionner des cas de test, je demanderais au responsable produit de déterminer qui peut effectuer quelle action sur quel objet. Prenons l’exemple fictif d’un service de gestion de documents comportant deux locataires, une adhésion au projet, des utilisateurs pouvant consulter et modifier les documents, ainsi qu’une autorisation d’exportation distincte. Un administrateur de locataire gère les adhésions mais ne peut pas lire automatiquement tous les documents. Un éditeur peut réviser un document actif mais ne peut pas modifier son locataire ni lever une consigne de conservation. Il s’agit là d’exemples de règles délibérées, et non d’hypothèses sur la manière dont chaque application devrait fonctionner.

NIST's attribute-based access-control guidance evaluates subject, object, requested operation and sometimes environmental attributes against policy or relationships (Hu et al., 2014). That gives us a useful vocabulary, but the vocabulary does not supply the business rule. For this service, I would represent a decision as P(subject, action, object, context, policy_version). Context includes the tenant relationship and relevant object state. A role is one input, not the whole predicate. An editor role without the project relationship should not grant access.

Le résultat attendu doit provenir d’une spécification pouvant diverger de l’implémentation. Si votre test appelle la fonction de politique de production pour calculer sa propre réponse attendue, une erreur commune aux deux parties peut passer inaperçue. Je demanderais au Product Owner et à un deuxième ingénieur d’examiner un petit tableau de décision, puis d’encoder les résultats attendus de manière indépendante. Ce tableau fait office d’oracle au sens des tests : il s’agit d’une description explicite du comportement correct. Il peut toutefois contenir des erreurs ; les règles ambiguës constituent donc des défauts de spécification qu’il convient de résoudre avant de déclarer la couverture.

Attribute provenance belongs in that table. The server can receive an object ID or requested tenant from a client, but it should establish their meaning through trusted state. A client-supplied owner_id is a requested value, not evidence of ownership. Hu et al. (2014, §§3.2.2.4–3.2.2.10) discuss integrity, authoritative attribute sources and attribute management. My application of that guidance is to record the source and freshness requirement for each consequential input. Otherwise, a carefully written policy may evaluate facts the caller was allowed to invent.

Autorisations distinctes pour les objets, les fonctions et les champs

Une autorisation au niveau de l’objet défaillante concerne l’accès à un objet particulier via une fonction que l’appelant peut utiliser. Les recommandations API1 de l’OWASP exigent de vérifier l’autorisation pour l’action demandée sur l’enregistrement concerné et expliquent pourquoi la comparaison d’un identifiant d’utilisateur de session avec un identifiant d’objet arbitraire est insuffisante (OWASP Foundation, 2023a). Dans le service hypothétique, un lecteur peut utiliser le point de terminaison de lecture de document, mais uniquement pour les documents couverts par une relation explicite. Des identifiants imprévisibles peuvent compliquer la détection ; ils n’établissent pas cette relation.

L’autorisation de fonction détermine si l’appelant est autorisé à invoquer l’opération. L’API5 de l’OWASP distingue ce problème et recommande des autorisations explicites avec refus par défaut (OWASP Foundation, 2023c). La lecture d’un document ne doit pas impliquer l’autorisation de modifier l’appartenance à un groupe ou de créer une exportation. Je testerais chaque opération directement via un client de test approuvé. La décision du navigateur de masquer un bouton n’a pas sa place dans le résultat attendu de l’autorisation côté serveur.

Field permission is another boundary. OWASP API3 addresses both excessive disclosure of object properties and unauthorized modification of sensitive properties (OWASP Foundation, 2023b). In our example, permission to edit a document title does not include changing tenant_id, owner_id or hold_state. Test the returned representation as well as the accepted input. A successful title update that also changes a protected field is an authorization failure even if the response omits that field.

Je consignerais ces éléments comme des obligations distinctes plutôt que de les regrouper sous la forme « le point de terminaison nécessite une authentification ». Cela permet de rendre les défaillances exploitables : la fonction incorrecte nécessite une protection opérationnelle ; l’objet incorrect nécessite une vérification de relation ; la propriété incorrecte nécessite un contrat de lecture ou d’écriture plus restrictif. Une seule requête peut enfreindre plusieurs obligations. La classification aide à identifier la décision manquante, mais elle ne doit pas retarder la correction d’un chemin d’accès avéré menant à des données non autorisées ou à une modification non autorisée.

Établir la validité d’un jeton sans la confondre avec le droit d’accès

Pour les API utilisant le profil de jeton d’accès JWT de la norme RFC 9068, le serveur de ressources vérifie le type de jeton, l’émetteur, le destinataire, la signature et la date d’expiration. Le profil précise également que les revendications d’autorisation doivent être évaluées à la lumière d’autres éléments de contexte disponibles ; il ne définit pas la politique d’objet de l’application (Bertocci, 2021, § 4). Il s’agit là de tests distincts. Un jeton signé par un émetteur de confiance pour un autre service devrait échouer à la validation du jeton, tandis qu’un jeton valide pour ce service peut néanmoins échouer au contrôle de la relation entre les documents.

RFC 9700 recommends restricting access-token privileges and audiences and checking whether the token is intended for the requested resource and action (Lodderstedt et al., 2025, §2.3). A scope such as documents:read can bound an operation without identifying every document the subject may read. I would therefore include a valid, correctly scoped token in cross-tenant tests. Using an expired token for every denied case tests authentication failure and never reaches the authorization decision you intended to examine.

Certains systèmes utilisent des jetons opaques et l’introspection à la place de la validation JWT locale. La norme RFC 7662 fournit un moyen d’interroger l’activité des jetons et le contexte associé, tout en identifiant explicitement le compromis de sécurité engendré par les réponses mises en cache (Richer, 2015, §§ 2.2, 4). L’introspection ne récupère pas automatiquement l’adhésion la plus récente de votre application à un projet. Précisez quelle autorité est responsable de chaque élément : l’activité des jetons, l’appartenance aux locataires, les relations entre objets et l’état métier peuvent résider dans des systèmes différents et évoluer selon des calendriers différents.

Cette distinction facilite également le diagnostic. Indiquez si le rejet s’est produit au niveau de la validation du jeton, de la sélection de la fonction, de la politique d’objet ou de la politique de champ. Cette distinction est nécessaire en interne, même lorsque le client reçoit un message d’erreur délibérément atténué. Un test d’autorisation doit échouer s’il atteint la mauvaise couche, à moins que son objectif ne soit précisément de tester cette couche antérieure. Sinon, un service de connexion défaillant peut faire apparaître toute une suite de tests négatifs comme « verts », ce qui peut être trompeur.

Élaborez une matrice qui modifie une condition pertinente à la fois

Le guide de test versionné de l’OWASP recommande d’utiliser plusieurs utilisateurs dotés d’objets et de privilèges différents lors de l’évaluation des références directes aux objets (Fondation OWASP, s.d.-c). Je créerais des entités synthétiques dont les relations sont connues : un utilisateur disposant d’un droit de consultation, un utilisateur sans lien avec le sujet dans le même tenant, un utilisateur dans un autre tenant, un éditeur et un administrateur n’ayant pas accès aux documents. Utilisez des objets dont la propriété et l’état sont contrôlés, plutôt que de deviner des identifiants à partir de données clients réelles. Chaque test doit s’exécuter dans l’environnement et le périmètre d’évaluation convenus.

Commencez par une base de référence valide, puis modifiez une donnée d’entrée significative. Modifiez l’objet tout en conservant l’appelant valide ; modifiez l’appelant tout en conservant l’objet et la requête valides ; modifiez l’action demandée sans modifier la relation. Cela permet d’interpréter la différence. Si vous modifiez simultanément l’identité, le locataire, la méthode, le type de contenu et l’état de l’objet, un refus ne vous permettra pas de déterminer quelle condition a été appliquée. Les combinaisons plus complexes prendront toute leur importance par la suite, mais elles doivent s’appuyer sur des tests de composants bien compris.

Vous trouverez ci-dessous une matrice proposée pour le service de documents fictif. Il s’agit des résultats attendus dans le cadre de la politique exemplaire mentionnée, et non de résultats de tests observés.

Étude de cas	Modification contrôlée à la suite d’une demande autorisée	Résultat attendu	Remarque : à vérifier
A	Aucun : le visualiseur actuel lit un document attribué	Autoriser	Représentation correcte autorisée
B	Remplacer un document sans rapport dans le même locataire	Refuser	Aucun contenu protégé ni aucune métadonnée
C	Remplacer un document dans un autre tenant	Refuser	Aucun contenu étranger et aucun effet inter-locataires
D	Le visualiseur lance l’opération d’exportation sans disposer de l’autorisation nécessaire	Refuser	Aucune tâche d’exportation ni aucun artefact téléchargeable
E	L’éditeur ajoute un champ de propriété protégé à une modification valide	Le rejeter ou l’exclure conformément au contrat	Le champ stocké protégé reste inchangé
F	Supprimez l’adhésion au projet, puis répétez l’opération avec le même jeton valide	Refuser dans les limites de propagation définies	Version et date de la décision consignées
G	Mélanger des documents autorisés et interdits dans une opération en masse	Respecter le contrat atomique ou de résultat partiel spécifié	Vérification du résultat et des effets secondaires de chaque objet
H	Perte d’accès après la mise en file d’attente d’une exportation mais avant la récupération	Respectez la politique explicite en matière d’emploi et de recherche	Aucun téléchargement en dehors du périmètre autorisé

Un refus attendu nécessite l’existence d’un objet connu. Dans le cas contraire, le service pourrait renvoyer un message « introuvable » car le dispositif n’a jamais été créé. Vérifiez l’existence de l’objet via le compte de contrôle autorisé, puis testez le sujet non autorisé sans modifier l’objet. Maintenez la configuration du dispositif en dehors de l’opération évaluée et effectuez le nettoyage via un chemin autorisé distinct. Une opération de nettoyage qui supprime les preuves avant l’exécution des assertions peut dissimuler une écriture involontaire.

Je conserverais également un contrôle valide après modification des autorisations. La suppression de l’accès d’un utilisateur ne devrait pas rendre le document inaccessible à tous. La requête refusée et la requête autorisée qui subsiste permettent ensemble de distinguer une limite fonctionnelle d’un service indisponible. Pour les opérations sensibles à l’état, enregistrez la transition exacte : un objet archivé, un objet mis en attente et un objet supprimé peuvent nécessiter des résultats différents. Le terme « inactif » est trop vague si la mise en œuvre traite ces états différemment.

Observez l’effet, et pas seulement le code de réponse

La sémantique HTTP permet à un serveur d’origine de renvoyer un code 404 afin de dissimuler l’existence d’une ressource interdite ; le code 403 indique le refus de satisfaire la requête (Fielding et al., 2022, §§ 15.5.4–15.5.5). Aucun de ces codes d’état, pris isolément, ne prouve que l’application a appliqué la politique prévue. Le corps de la réponse pourrait contenir un champ interdit, ou un gestionnaire pourrait ne rejeter la requête qu’après avoir mis la tâche en file d’attente. Je préconiserais de distinguer le résultat visible de l’extérieur et les effets durables pertinents.

Pour une opération d’écriture, vérifiez l’état protégé via un chemin de lecture fiable après la requête. Pour une opération d’exportation, vérifiez à la fois la création de tâches et la récupération d’artefacts. Pour une invitation, vérifiez si un message ou un changement d’adhésion s’est produit. Dans la méthode proposée ici, « refusé » signifie qu’aucun effet interdit ne se produit dans le cadre du contrat d’opération choisi. La journalisation de sécurité légitime est un effet attendu ; un e-mail non autorisé contenant le contenu d’un document ne l’est pas. La fenêtre d’observation doit couvrir les effets différés plutôt que de s’arrêter à l’arrivée de la réponse HTTP.

Les interfaces de collecte nécessitent leurs propres preuves. La recherche, la pagination, les décomptes, les aperçus et les téléchargements en masse peuvent exposer des informations qu’un point de terminaison de détail dissimule correctement. Insérez des marqueurs synthétiques distincts dans les enregistrements interdits, puis recherchez ces marqueurs dans tous les formulaires de sortie pertinents. Testez également les ensembles de résultats vides et mixtes. Une réponse qui masque l’enregistrement mais inclut son titre dans un message d’erreur enfreint tout de même une politique protégeant ce titre. Il s’agit d’une stratégie d’observation spécifique à l’application, et non d’une affirmation selon laquelle chaque différence de nombre ou de durée présente le même degré de sensibilité.

Déterminez quelles divulgations d’existence sont pertinentes avant d’interpréter les résultats. Un catalogue public peut révéler intentionnellement l’existence d’un document tout en protégeant son contenu ; un système de gestion des dossiers privés peut interdire même cette divulgation. Les tests de synchronisation nécessitent des mesures répétées et des contrôles du bruit. Une seule réponse plus lente ne constitue pas la preuve d’un canal d’inférence fiable. Je ferais la distinction entre une exposition confirmée du contenu, un signal d’existence reproductible et une observation temporelle non concluante, plutôt que de qualifier ces trois éléments de même défaut.

Tester le délai entre la modification des autorisations et leur application

L’autorisation est une revendication temporelle. Supposons qu’un responsable de projet supprime un utilisateur autorisé à consulter, reçoive un accusé de réception confirmant la réussite de l’opération, puis ajoute une pièce jointe confidentielle. L’utilisateur supprimé peut-il lire la nouvelle pièce jointe à l’aide de l’ancien jeton ? La réponse dépend de la cohérence de la politique, et non simplement de l’expiration du jeton. Pang et al. (2019, §2.2) décrivent le problème du « nouvel ennemi » dans Zanzibar : un état de contrôle d’accès obsolète peut exposer un nouveau contenu à une personne dont l’accès a été supprimé. Leur conception respecte l’ordre entre les modifications du contrôle d’accès et celles du contenu. Il s’agit d’une preuve d’existence d’une approche de conception, et non d’une preuve que votre application offre ces garanties.

Dans notre exemple, je préciserais si l’accusé de réception de la suppression signifie que le refus est effectif partout ou simplement que la propagation a commencé. Définissez l’événement de départ observable, le délai autorisé, les opérations affectées et le traitement des requêtes déjà en cours d’exécution. « La révocation est immédiate » n’est pas une promesse vérifiable tant que ces conditions n’ont pas été fixées. Une mesure commençant lorsqu’un administrateur clique sur un bouton diffère de celle qui commence lorsque le référentiel de politiques faisant autorité valide la modification.

Utilisez une planification contrôlée pour tester la limite. Établissez une requête autorisée, supprimez l’adhésion, attendez l’accusé de réception défini, puis répétez l’opération avec le même jeton pour chaque instance de service ou région concernée. Testez à la fois le contenu existant et le contenu ajouté après la suppression. Enregistrez la révision de la politique utilisée pour la décision là où l’architecture la rend visible. Si le service ne peut pas signaler cette révision, indiquez quelles preuves moins solides sont disponibles plutôt que d’inventer une garantie de cohérence précise.

La mise en cache nécessite un modèle de la chaîne réelle. Un cache de décision local peut renouveler une entrée à partir d’un cache d’attributs dont les données sont déjà obsolètes. Sa durée de vie nominale ne limite donc pas nécessairement le délai de révocation de bout en bout. À l’inverse, plusieurs caches consultés simultanément n’additionnent pas automatiquement leurs durées de vie. Je chercherais à déterminer qui actualise à partir de qui, quelle version accompagne les données et quelle invalidation est prise en compte. Ne calculez une limite qu’une fois ces hypothèses établies, puis effectuez des tests à proximité de cette limite. L’avertissement de la norme RFC 7662 concernant la mise en cache par introspection corrobore cette préoccupation spécifique aux jetons ; l’analyse plus large de la chaîne de caches présentée ici constitue la méthode d’application que je propose.

Associer l’autorisation à le changement d’état qu’elle autorise

Une décision en cours peut encore devenir obsolète avant que l’écriture ne soit validée. Imaginez qu’un éditeur passe le contrôle d’autorisation, qu’une deuxième transaction transfère le document vers un autre locataire, puis que la première requête effectue une écriture en utilisant uniquement l’identifiant du document. Le fait que cette écriture soit autorisée ou non dépend de la sémantique de transaction que vous avez prévue. Une vérification effectuée plus tôt dans le gestionnaire ne garantit pas, à elle seule, que l’état pertinent était le même au moment de la validation.

Je demanderais au service d’ingénierie d’identifier le point de linéarisation : le moment où le système considère que l’opération a pris effet. Selon la conception du stockage, une transaction, une mise à jour conditionnelle atomique ou une condition préalable liée à une politique ou à une version peut lier la décision à la mise à jour. Il s’agit là de conceptions possibles, et non de recettes interchangeables. Une condition de version n’est utile que si chaque modification pertinente au regard de la politique fait progresser la version vérifiée ; une transaction locale dans la base de données ne peut pas automatiquement intégrer un service d’adhésion distant dans la même décision atomique.

Testez ce raisonnement à l’aide d’un entrelacement contrôlé dans un environnement de test hors production. Faites une pause après l’évaluation de la politique, modifiez l’état de propriété ou d’appartenance concerné, puis reprenez l’opération. Le résultat attendu peut être un rejet, une nouvelle tentative avec une nouvelle évaluation, ou l’achèvement de l’opération en vertu d’un instantané d’autorisation antérieur clairement documenté. Ce qui importe, c’est que le résultat corresponde au contrat déclaré et ne franchisse pas silencieusement une frontière entre locataires. Un test de charge aléatoire peut ne jamais mettre en œuvre l’entrelacement critique ; son absence d’échecs constitue donc une preuve insuffisante de cette propriété.

Pour une opération en masse, déterminez si l’échec de l’autorisation sur un élément annule l’ensemble du lot. Si des résultats partiels sont autorisés, chaque élément traité doit tout de même faire l’objet d’une décision justifiée et d’une réponse bien délimitée. Si un comportement « tout ou rien » est promis, vérifier les objets un par un tout en validant chacun d’entre eux immédiatement contredit cette promesse. Je testerais un élément interdit au début, au milieu et à la fin, puis j’examinerais l’état qui en résulte. Cette approche modifie ce qu’une implémentation avec sortie anticipée aurait pu déjà effectuer.

Le comportement de réessai mérite un cas à part lorsque l’API utilise des clés d’idempotence pour éviter les doublons. Dans le service hypothétique, une requête d’exportation réussie pourrait être réessayée après la suppression de l’adhésion de l’utilisateur. Déterminez si ce réessai peut renvoyer un accusé de réception, révéler le résultat d’origine ou déclencher une nouvelle action. Ces résultats ont des implications différentes. Un mécanisme qui empêche les exécutions en double ne doit pas se transformer tacitement en autorisation de divulguer un résultat antérieur à un appelant qui ne peut plus le récupérer.

Je répéterais une requête contrôlée avec la même clé après la modification pertinente des autorisations, puis j’essaierais cette clé à partir d’un principal de test différent. Vérifiez à la fois la réponse et si l’opération a été répétée. Le résultat attendu dépend du contrat de relecture documenté, mais une réponse mise en cache doit rester dans le périmètre de divulgation autorisé du principal demandeur. Associez les preuves de test à l’appelant et au contexte de l’opération, ainsi qu’à la clé. Il s’agit d’une proposition de vérification d’application ; nous ne prétendons pas qu’une file d’attente ou un cadre API particulier mette automatiquement en œuvre ce comportement.

Assurer la bonne attribution des autorisations via les services et les files d’attente

Une passerelle connaît souvent l’entité externe ; un service en aval peut ne voir qu’un identifiant de charge de travail. La norme NIST SP 800-204 distingue les politiques d’accès communes des décisions plus fines, plus proches du microservice, et aborde le problème de cohérence créé par l’application distribuée (Chandramouli, 2019, § 4.1). Je tracerais le cheminement depuis le point d’entrée jusqu’à l’opération sur les données et j’identifierais à quel moment chaque composant identifie l’entité, l’objet et l’action. L’emplacement sur un réseau privé ne saurait se substituer à cette détermination de l’autorité.

Il existe une différence fondamentale entre un service agissant sous sa propre autorisation et un service agissant pour le compte d’un utilisateur. La norme RFC 8693 définit un échange de jetons prenant en charge la délégation et l’usurpation d’identité ; sa revendication d’acteur permet d’identifier l’acteur actuellement délégué (Jones et al., 2020, §§ 1.1, 4.1). L’utilisation de ce protocole ne détermine pas quelles actions votre employé est autorisé à effectuer. Le service destinataire doit toujours valider le contexte de confiance et appliquer sa propre politique. Un identifiant d’utilisateur copié à partir d’un en-tête non fiable n’équivaut pas à une délégation vérifiée.

Les tâches en file d’attente doivent avoir une durée de vie explicitement définie. Pour l’exportation hypothétique, j’opterais pour une revalidation avant l’exécution et avant le téléchargement, avec annulation si l’utilisateur à l’origine de la demande perd la relation requise. Un autre service peut délibérément exécuter une instruction métier préalablement approuvée en vertu d’une autorité organisationnelle distincte. Cela peut être légitime, mais l’autorité, le champ d’application et les règles d’annulation doivent être précisés. Cela ne doit pas se produire accidentellement parce qu’un consommateur de file d’attente dispose d’un large accès aux services et ne consulte plus jamais la décision d’origine.

La séquence de test suit ces décisions : mise en file d’attente tant que cela est autorisé, modification de l’appartenance avant l’exécution, vérification de l’exécution du travailleur, puis tentative de récupération dans l’état modifié. Répétez l’opération avec suppression après l’exécution mais avant le téléchargement. Incluez le chemin de livraison de l’artefact : le blocage du point de terminaison « job-status » est insuffisant si le fichier résultant reste accessible ailleurs sous une autorisation de livraison toujours valide. Enregistrez la durée de vie et le comportement de révocation de cette autorisation distincte. Un identifiant de tâche, un identifiant d’artefact et une capacité de téléchargement peuvent représenter trois surfaces d’autorisation différentes.

Suivre une exportation depuis la requête jusqu’aux octets téléchargés

Un test d’exportation concret nécessite plus de deux utilisateurs et un identifiant de tâche échangé. Je créerais deux locataires synthétiques avec des enregistrements distincts, ainsi qu’un deuxième utilisateur au sein du premier locataire qui ne dispose pas d’autorisation d’exportation. Attribuez délibérément aux locataires des noms de rapports et des identifiants locaux similaires lorsque le modèle de données le permet. Le résultat attendu doit permettre d’identifier les données de quel utilisateur peuvent apparaître, quels champs sont autorisés et quel sujet peut obtenir l’artefact finalisé. Aucun de ces éléments de test ne doit contenir de véritables informations client.

Suivez le parcours de l’exportation à travers cinq objets : la requête initiale, la tâche mise en file d’attente, la sélection de données par le travailleur, l’artefact stocké et l’autorisation de livraison. Enregistrez la liaison avec le locataire de confiance pour chaque transition. Un identifiant de tâche appartenant au locataire A ne doit pas permettre à un travailleur de sélectionner les enregistrements du locataire B au seul motif qu’un message contient un champ de locataire contradictoire. Les recommandations de OWASP relatives à l’architecture multi-locataires mettent explicitement en garde contre le fait de considérer un identifiant de locataire mis en file d’attente comme une preuve d’autorisation sans authentifier le chemin du producteur ni autoriser l’opération du consommateur (Fondation OWASP, s.d.-b).

Le test doit mettre à l’épreuve le transfert plutôt que le simple point de terminaison public. Dans un environnement d’intégration autorisé, fournissez une relation de tâche valide associée à une ressource ou à un locataire délibérément incompatible, puis observez la décision du consommateur. Si le message est rejeté par un analyseur syntaxique avant le contrôle d’autorisation, conservez ce résultat comme preuve de la validation des données d’entrée, puis constituez un dossier valable concernant la frontière de confiance elle-même. Ne déduisez pas l’autorisation d’un utilisateur à partir d’une requête que celui-ci n’a jamais eu à interpréter.

Database protections need the same scrutiny. PostgreSQL 18 documents that superusers and roles with BYPASSRLS bypass row security, while table owners normally bypass it unless subjected to FORCE ROW LEVEL SECURITY (PostgreSQL Global Development Group, n.d.). A test run under a restricted API role says little about an export worker that connects with a different role. Inspect and test the worker's actual database authority before crediting row-level security with protecting its query.

Lorsque l’application fournit le contexte du locataire via des connexions à la base de données mises en commun, incluez un cas de réutilisation : traitez le locataire A, puis le locataire B au cours du même cycle de vie de connexion autorisé, en tenant compte d’une défaillance intermédiaire. L’OWASP recommande un isolement fiable ou une réinitialisation des paramètres du locataire au niveau de la session et privilégie les paramètres locaux à la transaction pour cette préoccupation (Fondation OWASP, s.d.-b). Le constat d’acceptation est que l’opération de B ne voit que les lignes autorisées pour B ; le fait de voir un appel de réinitialisation dans le code ne prouve pas que chaque chemin d’exception l’ait exécuté.

Inspectez l’artefact produit indépendamment de la réponse relative à l’état de la tâche. Comparez les marqueurs d’enregistrements synthétiques, les champs autorisés et les relations attendues entre les lignes. Un collaborateur pourrait attribuer correctement l’étiquette du locataire A à un fichier contenant les données du locataire B. La conformité des métadonnées n’équivaut pas à la conformité du contenu. À l’inverse, la correspondance avec un seul marqueur attendu ne prouve pas que le fichier ne contient aucun enregistrement interdit supplémentaire. Le dispositif de test doit permettre de vérifier à la fois la présence obligatoire et la présence interdite.

Appliquez la même rigueur à la réutilisation des exportations et à la mise en cache. Deux locataires demandant le même modèle de rapport et la même plage de dates ne doivent pas entrer en conflit lors d’une recherche d’artefact partagé. L’OWASP recommande d’utiliser des clés de cache tenant compte du locataire, d’autres attributs influant sur les résultats si nécessaire, ainsi qu’une autorisation préalable à la lecture des valeurs mises en cache protégées (Fondation OWASP, s.d.-b). La séparation des clés et l’autorisation constituent des contrôles distincts : un cache correctement nommé peut tout de même divulguer un artefact si un point de terminaison accepte un espace de noms arbitraire provenant de l’appelant.

Un téléchargement signé entraîne une nouvelle transition d’autorité. AWS décrit les URL pré-signées S3 comme des jetons au porteur dont les capacités sont limitées par les autorisations de leur créateur (Amazon Web Services, s.d.). Une fois émise, l’URL n’est pas automatiquement liée à l’utilisateur de l’application qui l’a reçue. Vérifiez si un sujet non autorisé peut obtenir une autorisation de livraison valide d’un autre locataire ; ne confondez pas cette faille avec la capacité, documentée séparément, d’un destinataire légitime à copier une URL au porteur.

Cette distinction peut mettre en évidence une contradiction dans l’exigence du produit. Si l’exigence stipule que l’accès prend fin immédiatement lorsque l’adhésion est supprimée, une autorisation de stockage délivrée précédemment et dotée d’une durée de vie indépendante peut ne pas y satisfaire. L’exemple précédent de revalidation au moment du téléchargement nécessite donc une conception de la livraison capable d’effectuer cette vérification, ou une période explicitement acceptée pendant laquelle les autorisations existantes restent utilisables. Une application ne peut imposer sa propre décision de renouvellement d’adhésion à une demande de stockage directe qu’elle ne reçoit jamais.

Pour disposer d’un enregistrement d’acceptation reproductible, conservez l’identité de l’initiateur, le locataire, l’identité de la tâche, la portée des données sélectionnées, l’identité de l’artefact, la classe d’autorisation de livraison et l’état de la politique concernée. Ne conservez pas de jetons porteurs actifs dans les rapports de test courants. Appliquez le même scénario de test au statut de la tâche, aux tentatives de réessai, à l’annulation, aux métadonnées de l’artefact et à l’émission de téléchargement, lorsque ces opérations existent. Un point de terminaison d’annulation qui révèle un nom de fichier interdit constitue une divulgation, même si le travailleur ne produit jamais ce fichier.

Les preuves ainsi obtenues doivent permettre d’identifier la transition défaillante. La création non autorisée d’une tâche, une requête de données comportant des privilèges excessifs, la réutilisation d’artefacts entre locataires et la délivrance incorrecte d’une autorisation de livraison nécessitent des corrections différentes. Conservez un exemple d’exportation autorisée réussie à côté des cas négatifs, afin qu’une implémentation rejetant tout ne puisse pas être validée. Il s’agit d’un dispositif de test de bout en bout proposé, et non d’un test d’application documenté ni d’une affirmation selon laquelle un seul exercice d’exportation couvrirait toutes les obligations d’autorisation des API.

Rendre visibles les défaillances des politiques et la couverture des tests

Un service de politique centralisé réduit les doublons dans les définitions de règles, mais ajoute une dépendance. Une bibliothèque locale réduit une dépendance réseau, mais peut présenter des divergences d’un déploiement à l’autre. La fiche pratique sur l’autorisation de l’OWASP recommande le refus par défaut, la validation des autorisations à chaque requête et la gestion sécurisée des échecs d’autorisation (Fondation OWASP, s.d.-a). Je maintiendrais une distinction entre « la politique refuse cette action » et « le système n’a pas pu obtenir une décision fiable ». Ces deux cas peuvent empêcher l’action protégée sans pour autant prétendre qu’il s’agit du même événement opérationnel.

Testez un référentiel de politiques indisponible, une recherche d’attribut ayant dépassé le délai d’attente, des données de politique mal formées et un message d’invalidation ayant échoué. Vérifiez si une nouvelle tentative, un repli ou un disjoncteur de circuit génère une autorisation qui n’a jamais été accordée. Si l’entreprise exige une utilisation limitée de la dernière décision connue, précisez exactement quelles actions, quelle version des données et quelle durée maximale sont concernées. Considérez cela comme une décision de risque explicite et effectuez des tests distincts. Une branche « fail-open » non documentée ne constitue pas une stratégie de disponibilité que vous pouvez examiner de manière pertinente.

La couverture doit être évaluée par rapport aux obligations d’autorisation, et non pas uniquement au nombre de points de terminaison. Dix routes peuvent partager une même politique correctement appliquée, tandis qu’une seule route peut exposer des lectures, des mises à jour, des exportations et des objets imbriqués avec des décisions différentes. Maintenez une correspondance entre chaque obligation et les points d’entrée, les fixtures et les assertions pertinents. Les tests unitaires examinent les combinaisons de règles ; les tests d’intégration examinent l’identité réelle et les chemins de données. Aucun ne remplace l’autre. Les tests unitaires d’une bibliothèque partagée ne peuvent pas démontrer que chaque utilisateur l’invoque avant d’agir.

J’inclurais des vérifications de défauts délibérés dans un environnement de test isolé : supprimer une condition de relation obligatoire ou contourner une restriction de champ, puis vérifier que le test correspondant échoue. Cela permet de déterminer si la suite de tests est capable de détecter le défaut qu’elle prétend couvrir. Cela ne permet pas d’estimer la prévalence des vulnérabilités en production. Indiquez quelles classes de défauts ont été détectées et quelles limites n’ont pas encore été testées. Un pourcentage sans ce dénominateur peut cacher plus de choses qu’il n’en explique.

Déterminez ce que les preuves permettent d’étayer

Pour un examen de version, je rassemblerais le tableau des autorisations approuvées, les versions déployées des politiques et des applications, les relations entre les éléments de test, les observations autorisées et refusées, les résultats des transitions d’état, les observations à effet différé et les exclusions non résolues. Le réviseur doit être en mesure de suivre une règle de conséquence depuis sa signification métier jusqu’à une assertion concrète. Les journaux peuvent étayer cette traçabilité à l’aide d’un identifiant de corrélation, d’un motif de décision et d’une version de politique ; les jetons bruts et les charges utiles des clients n’ont pas leur place dans le dossier de preuves. Utilisez des identifiants synthétiques et ne conservez que ce qui est nécessaire pour reproduire le résultat.

Le critère de validation que je propose est délibérément plus restrictif que « l’autorisation est sécurisée ». Pour le périmètre et la configuration désignés, toutes les obligations impératives disposent de cas de contrôle valides, aucune donnée interdite ni aucun effet interdit n’ont été observés dans les cas testés, et le comportement de transition a respecté le contrat de cohérence déclaré. L’absence d’observation d’un effet en file d’attente constitue une preuve incomplète, et non une validation. Une lecture ou une écriture inter-locataires confirmée contredit la limite fondamentale et nécessite une correction avant que cette méthode puisse valider l’acceptation. Les autres exclusions doivent être accompagnées d’une conséquence clairement identifiée et d’un responsable de la décision.

Il existe des limites. Le modèle d’autorisation peut omettre une relation commerciale ; l’environnement de test peut différer de l’environnement de production ; les politiques dynamiques peuvent créer des combinaisons dépassant le cadre d’une matrice finie. Les tests par paires peuvent réduire le nombre de combinaisons, mais ne prouvent pas que les interactions entre trois attributs ou plus sont sûres. La vérification formelle peut renforcer le raisonnement concernant un modèle tout en laissant de côté, dans ses hypothèses, la propagation d’identité, l’actualité des données et le câblage de déploiement. J’utiliserais chaque technique pour l’affirmation qu’elle est réellement en mesure d’établir.

La principale objection d’ordre pratique réside dans le coût. Les petites équipes ne peuvent pas tester toutes les permutations à chaque validation. Commencez par l’isolation des locataires, les actions privilégiées, les champs sensibles et les chemins de révocation, puis conservez les cas de régression à mesure que le produit évolue. Cette hiérarchisation doit être explicite. « Nous avons testé les obligations ayant les conséquences les plus graves » est un résultat honnête ; « chaque chemin d’autorisation possible est vérifié » va généralement au-delà des preuves disponibles. La méthode présentée ici n’a pas fait l’objet d’une évaluation empirique en tant que programme complet, et les normes citées ne valident pas son efficacité pour toutes les architectures.

Si vous souhaitez savoir si votre API sépare réellement les clients, demandez un briefing sur l’autorisation de l’API. Apportez le modèle d’autorisation et un compte rendu anonymisé des chemins d’accès aux requêtes. Je peux vous aider à les transformer en un périmètre d’évaluation, une matrice de test reproductible et une décision de mise en production liée à un comportement observable. Concernant la question connexe de l’identité des services, consultez l’article « À qui appartiennent les identités utilisées par vos services cloud ? » ; ce document examine ce que ces identités peuvent faire sur des objets particuliers.