Sujet : authorization
-
Choisir les points de contrôle des autorisations pour les tâches en file d'attente après révocation de l'accès
Rendre explicite le moment où l'autorisation s'applique lorsqu'une requête planifie un travail exécuté plus tard. L'exercice proposé sépare l'autorisation de mettre un travail en file d'attente de celle de l'exécuter et d'en récupérer le résultat.
-
Vérifier qu'un contournement d'urgence prend fin en même temps que son autorisation
Vérifier le cycle de vie d'un contournement d'urgence explicitement approuvé dans un environnement contrôlé. La méthode proposée distingue l'autorisation ordinaire, l'autorité exceptionnelle temporaire et le retour à la politique ordinaire.
-
Maintenir l'application des autorisations lorsque des dépendances tombent en panne
Tester la décision de sécurité prise lorsqu'une dépendance requise est indisponible. Cette proposition originale d'injection de fautes rend visible le comportement de type fail-open, sans présumer que chaque service devrait renvoyer la même erreur ou la même réponse de disponibilité.
-
Tester que les mises à jour de profil ne peuvent pas modifier des champs de compte privilégiés
Créer une régression ciblée pour les mises à jour qui acceptent des données de profil ordinaires en même temps que des champs que l'appelant ne doit pas pouvoir contrôler. La méthode propose une propriété explicite des champs plutôt qu'une liste de contrôle générique de validation des entrées.
-
Transmission de jeton et « adjoint confus » dans les serveurs MCP qui appellent d'autres API
Un serveur MCP qui retransmet le jeton d'un client à une API en aval, ou qui utilise ses propres identifiants étendus pour le compte de quiconque le sollicite, laisse les parties appelantes agir avec une autorité qui ne leur a jamais été accordée. Les recommandations de sécurité MCP interdisent la transmission de jetons et décrivent le déroulement de l'attaque par « adjoint confus » pour les serveurs mandataires.
-
Tester les curseurs de continuation après un changement d'identité de la requête
Vérifier la politique de visibilité de l'application quand un curseur de continuation est réutilisé sous un principal différent. Cette méthode originale traite le curseur comme faisant partie d'un contexte de requête dont la signification en matière de sécurité doit être spécifiée.
-
Tester l'autorisation des transitions de flux de travail plutôt que l'accès aux écrans
Vérifier si un appelant peut effectuer une transition d'état particulière, y compris des transitions que l'interface actuelle n'expose pas. Cette méthodologie proposée vise les flux d'approbation dont la politique de sécurité dépend à la fois de l'identité et de l'état courant.
-
Vérifier qui peut restaurer un objet supprimé et ses anciennes permissions
Traiter la restauration d'un objet supprimé comme une nouvelle décision d'autorisation dotée d'une sémantique de permission explicite. Ce dispositif de test proposé vise l'écart entre la politique de suppression et le comportement de restauration.
-
Tester les changements de configuration qui modifient l'autorité d'un autre utilisateur
Repérer les écritures de configuration qui accordent indirectement des permissions, même lorsque leur point d'accès ressemble à une simple modification de paramètres. Cette proposition suit le changement d'autorité qui en résulte, plutôt que de juger du risque d'après le nom de la route.
-
Tester l'accès aux exports privés, de la demande jusqu'à leur suppression
Suivre un export privé à travers sa génération, sa récupération, son expiration et son nettoyage. La méthode proposée contrôle l'ensemble du cycle de vie de l'artefact, plutôt que de considérer comme suffisant un contrôle d'autorisation réussi à la création de l'export.
-
Distinguer un accès refusé d'une fixture de test négatif défaillante
Empêcher un agent de considérer n'importe quelle erreur comme la preuve qu'un test de contrôle d'accès a réussi. La méthode proposée utilise des témoins appariés pour déterminer si l'application a effectivement atteint la décision d'autorisation visée.
-
Tester l'autorisation par les relations aux ressources plutôt que par les noms de rôle
Vérifier si un appelant peut agir sur un objet particulier à travers la relation que le produit promet réellement. Cette méthode de laboratoire proposée traite les libellés de rôle comme des attributs du montage de test, pas comme l'oracle du test.
-
Séparer le service agissant de l'utilisateur représenté dans les tests de délégation
Tester une action déléguée avec à la fois l'identité du service exécutant et l'utilisateur qu'il représente visibles dans l'oracle. Cette méthode proposée évite de traiter une authentification de service réussie comme une preuve suffisante de l'autorité de l'utilisateur.
-
Vérifier que les routes de ressources imbriquées rattachent les enfants au parent déclaré
Valider une relation que des agents de programmation peuvent omettre lors de la construction de points de terminaison imbriqués : l'enfant demandé doit appartenir au parent demandé selon le contrat de l'application. Il s'agit d'une conception de montage de test originale.
-
Définir l'oracle d'autorisation pour les requêtes par lot portant sur des objets mixtes
Mettre au jour les règles d'accès ambiguës des opérations par lot avant qu'un agent n'écrive des tests approuvant quelle que soit la réponse que l'implémentation renvoie. La proposition se concentre sur la propriété mixte au sein d'une même requête.
-
Autorisation MCP 2026-07-28 : vérification de l'émetteur et évolution de l'enregistrement des clients
Cette révision renforce la validation de l'émetteur des réponses d'autorisation, lie les identifiants d'enregistrement stockés à leur émetteur et déprécie Dynamic Client Registration. Les Client ID Metadata Documents étaient déjà recommandés dans la révision précédente.
-
Vérifier l'acceptation d'une invitation par rapport au destinataire et à l'espace de travail prévus
Tester le lien entre une invitation, son destinataire prévu et son espace de travail de destination. La régression proposée vise les flux d'accueil écrits par des agents, qui autrement ne testent que l'acceptation réussie.
Lisible par machine : JSON