Outils de test de sécurité des API : quatre catégories, des rôles distincts

Outils de test de sécurité des API : les quatre catégories

La quatrième est la vérification comportementale: l'API refuse-t-elle ce qu'elle doit refuser ? Appels non authentifiés, accès entre comptes, limites de rôles, jetons expirés. Aucun scanner ne peut le vérifier, parce que cela dépend de ce que votre produit entend par permission.

La lacune de la plupart des équipes

Les équipes ont généralement un scanner dans leur pipeline et un test d'intrusion une fois par an. Les deux sont utiles. Ni l'un ni l'autre ne vérifie que l'endpoint livré mardi dernier applique bien l'autorisation au niveau des objets, qui est la faille la plus couramment exploitée dans les API réelles.

Si elle reste non vérifiée, la raison est organisationnelle plutôt que technique. Cela ressemble à un sujet de sécurité, donc on attend le processus de sécurité, qui tourne tous les trimestres. Il s'agit en réalité d'une vérification comportementale, qui a sa place dans la suite de tests exécutée à chaque modification.

Comment savoir quelle lacune est la vôtre

• Pouvez-vous dire quand quelqu'un a vérifié pour la dernière fois que l'utilisateur A ne peut pas lire les données de l'utilisateur B ? Si la réponse est le test d'intrusion annuel, cela fait une fenêtre de douze mois sur votre faille la plus probable.

• Un nouvel endpoint reçoit-il automatiquement une vérification des permissions ? Si cela repose sur le fait que l'auteur y pense, cela passera à la trappe.

• Les résultats du scanner sont-ils triés ou accumulés ? Un scanner qui produit des résultats que personne ne lit est pire que pas de scanner du tout, parce qu'il donne l'illusion d'une couverture.

Combler la lacune comportementale

Les plans d'API générés incluent des catégories d'autorisation et de limites, si bien que les vérifications de permissions coexistent avec la couverture fonctionnelle au lieu de constituer un exercice à part. Elles passent ainsi à une cadence « à chaque modification », la seule qui suive le rythme des nouveaux endpoints.

La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes du CLI se trouve dans le dépôt CLI.

Le fonctionnement est détaillé dans la documentation des tests d'API.

Le tri, ou pourquoi le scanner a cessé de compter

Les scanners échouent d'une manière précise et courante : ils continuent de fonctionner et plus personne ne les lit. Cela vaut la peine d'être compris, car ce n'est pas un problème d'outillage.

La première exécution produit une longue liste, en grande partie non pertinente. Personne n'a le temps de la traiter, on se contente donc de la survoler. L'exécution suivante produit la même liste plus deux nouvelles entrées, invisibles au milieu du bruit existant. En un trimestre, le rapport devient un artefact que l'on génère et que l'on archive, et un signalement légitime pourrait y dormir pendant un an.

Le remède n'a rien de glorieux : triez la première liste une bonne fois, correctement, et masquez ce qui ne s'applique pas en joignant une justification écrite. Ensuite, le rapport n'affiche plus que ce qui a changé, et cela, les gens le lisent vraiment. Un scanner dont les résultats ne sont jamais triés est pire que pas de scanner du tout, parce qu'il produit une apparence de couverture.

Quoi exécuter, et où

Les vérifications comportementales à chaque pull request. Les scanners selon une planification régulière. Les proxys et les fuzzers entre les mains de quelqu'un qui mène un travail ciblé. Un test d'intrusion quand le modèle de menace change, plutôt que quand le calendrier le dit.

Si le pipeline appartient à une autre équipe, la GitHub App est la voie de moindre résistance : c'est un webhook, elle ne modifie rien dans votre dépôt, et elle se déclenche quand votre build signale la mise en ligne de la nouvelle version. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions fait la même chose.

Ce que TestSprite apporte dans la quatrième catégorie

La vérification comportementale : l'API refuse-t-elle ce qu'elle doit refuser ? Les plans générés incluent des catégories d'autorisation et de limites, de sorte que chaque endpoint est contrôlé sur les accès non authentifiés, les lectures entre comptes, les limites de rôles et les identifiants expirés, à chaque modification.

L'outil s'exécute contre le service en fonctionnement, via son interface, en s'appuyant sur une passe de découverte et sur votre spécification pour savoir ce qui existe. Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables transmet les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution de ce dont chaque cas a besoin et de ce qu'il produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé.

Le gain : l'autorisation au niveau des objets ne dépend plus de la mémoire de quelqu'un. Votre scanner continue de traiter les dépendances et les classes d'injection, votre test d'intrusion continue de traiter les abus créatifs, et la catégorie qui se trouve entre les deux cesse d'être la responsabilité de personne.