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.
-
Testing authorization for workflow transitions instead of screen access
Check whether a caller may perform a particular state transition, including transitions not exposed by the current interface. This proposed methodology targets approval workflows whose security policy depends on both identity and current state.
-
Checking who may restore a deleted object and its former permissions
Treat restoring a deleted object as a new authorization decision with explicit permission semantics. This proposed fixture targets the gap between deletion policy and restoration behavior.
-
Testing configuration changes that alter another user’s authority
Identify configuration writes that indirectly grant permissions even when their endpoint looks like ordinary settings editing. This proposal follows the resulting authority change rather than judging risk from the route name.
-
Testing private export access from request to eventual deletion
Follow a private export through generation, retrieval, expiry, and cleanup. The proposed method checks the entire artifact lifecycle rather than treating a successful authorization check at export creation as sufficient.
-
Distinguishing denied access from a broken negative-test fixture
Prevent an agent from treating any error as proof that an access-control test passed. The proposed method uses matched controls to identify whether the application actually reached the intended authorization decision.
-
Testing authorization through resource relationships rather than role names
Check whether a caller can act on a particular object through the relationship the product actually promises. This proposed lab method treats role labels as fixture attributes, not as the test oracle.
-
Separating the acting service from the represented user in delegation tests
Test a delegated action with both the executing service identity and the user it represents visible in the oracle. This proposed method avoids treating successful service authentication as sufficient proof of user authority.
-
Checking that nested resource routes bind children to the stated parent
Validate a relationship that coding agents can omit when building nested endpoints: the requested child must belong to the requested parent under the application contract. This is an original fixture design.
-
Defining the authorization oracle for mixed-object batch requests
Expose ambiguous access rules in batch operations before an agent writes tests that approve whichever response the implementation happens to return. The proposal focuses on mixed ownership within one request.
-
Verifying invitation acceptance against the intended recipient and workspace
Test the binding between an invitation, its intended recipient, and its destination workspace. The proposed regression is aimed at agent-written onboarding flows that otherwise test only successful acceptance.
Lisible par machine : JSON