Les défaillances d’autorisation des API passent inaperçues : testez chaque objet, rôle et action

En bref : L’authentification prouve qui a effectué une requête ; l’autorisation détermine ce que cette identité est autorisée à faire. La sécurité des API est compromise lorsque les équipes testent la première question et supposent que la seconde est correctement gérée partout.

Un jeton valide n’est pas une autorisation

Les API modernes associent souvent une authentification robuste à des contrôles faibles au niveau des objets. Une requête peut contenir une session ou un jeton d’accès parfaitement valide tout en demandant la facture, le projet ou l’exportation d’un autre client, ou encore une action administrative. Si le gestionnaire vérifie uniquement que l’appelant est connecté, l’API répond à la mauvaise question de sécurité.

Cette défaillance passe facilement inaperçue, car les tests fonctionnels habituels suivent le parcours prévu. Le propriétaire ouvre son propre enregistrement, un administrateur utilise un point de terminaison réservé aux administrateurs, et chaque requête aboutit exactement comme prévu. Les défauts d’autorisation n’apparaissent que lorsque l’identité, l’objet, le locataire ou l’action sont délibérément incompatibles.

Établissez une matrice d’autorisation complète

• Testez chaque opération sur un objet en tant que propriétaire, utilisateur de même niveau au sein du même locataire, utilisateur d’un autre locataire et appelant non authentifié.
• Testez séparément les actions de lecture, de création, de mise à jour, de suppression, d’exportation, d’invitation et d’approbation ; la protection d’une méthode ne prouve pas que les autres le sont.
• Modifiez les identifiants dans les chemins, les paramètres de requête, les corps JSON, les en-têtes et les objets imbriqués au lieu de tester uniquement le champ évident de l’URL.
• Vérifiez les changements de rôle et les sessions obsolètes afin que les utilisateurs rétrogradés ou supprimés ne puissent pas conserver leurs privilèges par l’intermédiaire de revendications mises en cache.

Refusez par défaut à la frontière des données

La conception la plus fiable lie chaque requête à la fois à l’objet demandé et au périmètre autorisé de l’appelant. Récupérer un enregistrement par son identifiant puis vérifier sa propriété ultérieurement laisse la porte ouverte aux contrôles oubliés, aux canaux auxiliaires et à une gestion incohérente des erreurs. Effectuer la requête dans les limites du locataire ou de la propriété intègre la condition de sécurité au processus de récupération lui-même.

Les fonctions centralisées de gestion des politiques réduisent les divergences, mais elles ne remplacent pas les tests. Chaque point de terminaison nécessite toujours des assertions négatives prouvant que les identités non autorisées ne reçoivent aucune donnée et ne provoquent aucun changement d’état. Une réponse 403 ne constitue une preuve utile que si la base de données et les effets en aval restent intacts.

Les preuves doivent démontrer que le chemin interdit est resté fermé

Un test d’autorisation utile consigne l’appelant, le rôle, le locataire, l’objet ciblé, la requête, la réponse et l’état après la requête. Ces éléments permettent de distinguer un véritable contrôle d’une restriction de l’interface ou d’un code d’état masquant une action déjà exécutée.

KENSAI aborde la validation des contrôles d’accès comme une matrice plutôt que comme une simple analyse du parcours nominal. L’objectif est de prouver l’isolation entre les identités et les actions, puis de conserver suffisamment de preuves pour reproduire toute défaillance de la frontière d’accès et vérifier sa correction.

À retenir

L’autorisation est une relation entre une identité, un objet et une action. Testez ces trois dimensions avec des cas négatifs et prouvez que les requêtes interdites n’entraînent ni exposition de données ni effets secondaires.