Checklist de tests de sécurité des API : qui vérifie quoi

La checklist de tests de sécurité des API, regroupée selon qui effectue la vérification

Couvert par la vérification fonctionnelle automatisée

Ce sont des vérifications comportementales : l'API répond-elle correctement à une requête qu'elle devrait refuser ? Elles ont leur place dans votre suite habituelle et doivent s'exécuter à chaque modification.

• L'accès non authentifié est refusé. Chaque endpoint protégé, appelé sans identifiants, renvoie le rejet attendu plutôt que des données.

• L'autorisation est appliquée objet par objet. L'utilisateur A ne peut ni lire ni modifier les enregistrements de l'utilisateur B en changeant un identifiant dans le chemin. C'est la faille la plus exploitée dans les API réelles, et c'est une simple vérification comportementale.

• Les frontières entre rôles tiennent. Un rôle en lecture seule ne peut pas écrire. Un token expiré ou révoqué est rejeté.

• La validation des entrées rejette les valeurs hors plage. Les cas limites sur chaque paramètre, y compris ceux que personne ne documente.

• Les erreurs ne laissent rien fuiter du fonctionnement interne. Traces d'exécution, fragments de requêtes et noms d'hôtes internes restent en dehors des réponses.

Nécessite un scanner ou un outil spécialisé

• Vulnérabilités des dépendances et des bibliothèques.

• Familles d'injection : SQL, commandes, templates, désérialisation.

• Configuration TLS et gestion des certificats.

• Recherche de CVE connues sur votre stack.

Nécessite un humain

• Les abus de la logique métier. Commander une quantité négative, rejouer une remise, sauter une étape dans un processus qui supposait un ordre précis.

• La modélisation des menaces, et la décision de ce qui constitue réellement une donnée sensible.

• Tout ce qui demande de la créativité pour imaginer comment quelqu'un détournerait votre produit.

Le point que tout le monde saute

L'autorisation au niveau objet est le point le plus souvent absent et le plus facile à vérifier. Créez deux comptes, faites créer un enregistrement par l'un et essayez de le lire avec le token de l'autre. Si cela renvoie des données, vous avez la faille grave la plus répandue du secteur, et un seul test suffit à la trouver.

Automatiser cette vérification rentabilise l'exercice entier, car elle doit être répétée pour chaque nouvel endpoint et personne n'y pensera.

Faire tourner pour de bon la moitié automatisable

Les plans d'API générés incluent des catégories d'autorisation et de cas limites, de sorte que ces vérifications coexistent avec votre couverture fonctionnelle au lieu de former un exercice de sécurité distinct que personne ne planifie.

Le tableau de bord couvre le même périmètre pour ceux qui ne veulent pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt CLI.

Les détails de fonctionnement figurent dans la documentation des tests d'API.

Les deux comptes que vous devriez conserver en permanence

Presque tous les points comportementaux de cette liste nécessitent deux utilisateurs, et la chose la moins coûteuse à faire est de conserver une paire de comptes de test dans chaque environnement plutôt que de les créer test par test.

Faites-les différer sur les aspects qui comptent pour votre produit : propriétaires différents, rôles différents si vous en avez, idéalement organisations différentes. Chaque vérification d'autorisation devient alors un test de deux lignes plutôt qu'un travail de préparation, et les équipes les écrivent vraiment.

La version qui échoue consiste à créer les comptes à l'intérieur de chaque test. C'est plus lent, cela laisse des données derrière soi, et la vérification dépend alors du bon fonctionnement de votre parcours d'inscription : une inscription cassée fait passer au rouge tous les tests de permissions pour une mauvaise raison. Des comptes permanents, créés une fois pour toutes, éliminent tout cela.

Cadence par groupe

Vérifications comportementales à chaque modification. Scanners à intervalles réguliers et au moment des releases. Revue humaine quand le modèle de menaces change, c'est-à-dire quand vous ajoutez un nouveau type de donnée ou un nouveau type d'utilisateur.

Connectez le dépôt depuis le tableau de bord et les exécutions partent du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.

Comment TestSprite couvre le tiers automatisable

Les plans d'API générés incluent des catégories d'autorisation et de cas limites, de sorte que les points comportementaux de cette liste coexistent avec votre couverture fonctionnelle au lieu de former un exercice distinct que quelqu'un doit planifier.

Autrement dit, l'accès non authentifié, l'autorisation au niveau objet, les frontières entre rôles, les tokens expirés et les entrées hors plage sont vérifiés à chaque modification, sur le service en cours d'exécution, pour chaque endpoint, y compris ceux ajoutés la semaine dernière. Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables transporte 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éé.

La valeur tient à la cadence plus qu'à l'ingéniosité. Ces vérifications ne sont pas difficiles à écrire ; elles sont difficiles à ne pas oublier au quarantième endpoint. Les faire générer et exécuter en continu, c'est ce qui referme la faille la plus exploitée des API réelles sans ajouter un processus que quelqu'un doit suivre.