Après plus de 20 ans de création, c’est maintenant officiel : les API sont partout. Dans une enquête de 2021, 73% des entreprises ont déclaré qu’elles publiaient déjà plus de 50 API, et ce nombre ne cesse de croître.
Les API ont un rôle crucial à jouer dans pratiquement tous les secteurs aujourd’hui, et leur importance ne cesse d’augmenter à mesure qu’elles passent au premier plan des stratégies commerciales. Ce n’est pas surprenant : les API connectent de manière transparente des applications et des appareils disparates, apportant des synergies et des efficacités commerciales sans précédent.
Cependant, les API présentent des vulnérabilités comme tout autre composant du logiciel. De plus, s’ils ne sont pas rigoureusement testés du point de vue de la sécurité, ils peuvent également introduire une toute nouvelle gamme de surfaces d’attaque et vous exposer à des risques sans précédent. Si vous attendez la production pour découvrir les vulnérabilités de l’API, vous pouvez subir des retards substantiels.
Les API sont attrayantes pour les attaquants, pas seulement pour les entreprises
Gardez à l’esprit que les API font plus que simplement connecter vos applications ; ils modifient la fonctionnalité de manière imprévisible. La plupart des faiblesses uniques que les API peuvent introduire sont bien connues des pirates, qui ont développé différentes méthodes pour attaquer vos API afin d’accéder aux données et fonctionnalités sous-jacentes.
Selon le Top 10 des API OWASP, il n’est pas rare que des utilisateurs légitimes et authentifiés exploitent l’API en utilisant des appels qui semblent légitimes mais qui sont en fait destinés à manipuler l’API. Ce genre d’attaques, visant à manipuler la logique métier et à exploiter les défauts de conception, sont attrayants pour les attaquants.
Vous voyez, chaque API est unique et propriétaire. En tant que tels, ses bogues et vulnérabilités logiciels sont également uniques et « inconnus ». Le type de bogues qui conduisent à des attaques au niveau de la logique métier ou du processus métier est particulièrement difficile à identifier en tant que défenseur.
Accordez-vous suffisamment d’attention aux tests de sécurité des API ?
La sécurité Shift-left est déjà largement acceptée dans de nombreuses organisations, permettant des tests continus tout au long du développement. Cependant, les tests de sécurité des API passent souvent entre les mailles du filet ou sont effectués sans une compréhension suffisante des risques encourus. Pourquoi donc? Eh bien, il y a plus d’une raison :
- Les outils de test de sécurité des applications existants sont génériques et visent les vulnérabilités des applications Web traditionnelles, et ne peuvent pas gérer efficacement les complexités de la logique métier d’une API.
- Étant donné que les API n’ont pas d’interface utilisateur, il est courant que les entreprises testent séparément le Web, l’application et le mobile, mais pas l’API elle-même.
- Les API de test peuvent être intensives manuellement et ne sont pas évolutives lorsque vous en avez des centaines.
- L’expérience et l’expertise pertinentes peuvent être rares, car les tests API sont plus compliqués que les autres types de tests
- Avec les API héritées, vous ne connaissez peut-être pas les API déjà implémentées ou la documentation.
Ainsi, alors que la sécurité de décalage à gauche est déjà appréciée par de nombreuses organisations en général, les tests de sécurité des API sont trop souvent laissés de côté dans le cadre de DevSecOps.
C’est malheureux, car les vulnérabilités d’API nécessitent plus de temps pour être corrigées que les vulnérabilités d’applications traditionnelles – dans une enquête récente, 63 % des personnes interrogées ont déclaré qu’il fallait plus de temps pour corriger les vulnérabilités d’API. Ce nombre est également susceptible d’augmenter compte tenu de l’adoption rapide des applications et de la dépendance vis-à-vis des API.
Alors que la plupart des responsables de la sécurité sont conscients de l’importance des tests de sécurité des API, un peu moins de la moitié déclarent ne pas encore avoir de solution de test de sécurité des API pleinement intégrés dans leur pipeline de développement.
Pourquoi les approches de test de sécurité courantes ne couvrent-elles pas les API ?
Comme première étape vers une approche globale, il est important d’examiner les attitudes les plus courantes à l’égard des tests de sécurité des applications aujourd’hui : les tests de sécurité statiques et les tests de sécurité dynamiques.
Tests de sécurité statiques adopte une approche boîte blanche, créant des tests basés sur les fonctionnalités connues de l’application en examinant la conception, l’architecture ou le code, y compris les nombreux chemins complexes que les données peuvent emprunter lors de leur passage dans l’application.
Tests de sécurité dynamiques adopte une approche boîte noire, créant des tests basés sur les performances attendues de l’application compte tenu d’un ensemble particulier d’entrées, sans tenir compte du traitement interne ou de la connaissance du code sous-jacent.
En ce qui concerne les API, les développeurs et les équipes de sécurité se disputent fréquemment pour savoir laquelle des deux méthodes est la plus appropriée, le principal raisonnement en faveur de chacune étant :
- Le test statique est la seule méthode qui a du sens : puisqu’il n’y a pas d’interface utilisateur pour les API, vous devez savoir ce qui se passe dans la logique métier.
- Les tests dynamiques sont tout ce qui est nécessaire, car les tests unitaires utilisent des modèles statiques et ont déjà été effectués à un stade antérieur du pipeline.
Désolé de gâcher la fête, mais ces deux points ne sont que partiellement vrais. En fait, les deux approches sont nécessaires pour assurer une large couverture et gérer une variété de scénarios possibles. Surtout avec la montée actuelle des attaques basées sur les API, vous ne pouvez prendre aucun risque en matière d’évolutivité, de profondeur et de fréquence.
Les tests de sécurité de l’API « Grey-box » peuvent offrir une alternative intéressante. Comme il n’y a pas d’interface utilisateur, la connaissance du fonctionnement interne de l’application (par exemple, les paramètres, les types de retour) peut vous aider à créer efficacement des tests fonctionnels axés sur la logique métier.
Idéalement, combiner les aspects des tests de sécurité des API vous rapprocherait de la création d’une solution boîte grise qui compense les faiblesses de chacune de ces approches individuelles. Une telle approche de logique métier examinerait intelligemment les résultats d’autres types de tests et peut s’adapter pour appliquer des tests améliorés, automatiquement ou manuellement.
Il est temps d’adopter une approche de test de sécurité des API de logique métier
L’industrie est de plus en plus consciente de la nécessité de sécuriser les API tout au long de leur cycle de vie, en plaçant les API au premier plan de vos contrôles de sécurité.
Pour ce faire, vous devez trouver des moyens de simplifier et de rationaliser les tests de sécurité des API de votre organisation, en intégrant et en appliquant les normes de test de sécurité des API dans le cycle de développement. De cette façon, en plus de la surveillance de l’exécution, l’équipe de sécurité peut obtenir une visibilité sur toutes les vulnérabilités connues en un seul endroit. En prime, prendre des mesures pour déplacer les tests de sécurité des API vers la gauche réduira les coûts et accélérera le délai de résolution.
De plus, une fois vos workflows de test automatisés, vous disposerez également d’une prise en charge intégrée pour les retests : un cycle de test, de correction, de retest et de déploiement, assurant le bon fonctionnement de votre pipeline et évitant complètement les goulots d’étranglement.
Une approche logique métier des tests de sécurité des API peut augmenter la maturité de votre programme de sécurité des API du cycle de vie complet et améliorer votre posture de sécurité.
Cependant, cette approche moderne nécessite un outil capable d’apprendre au fur et à mesure, améliorant ses performances au fil du temps en ingérant des données d’exécution pour mieux comprendre la structure et la logique de l’application.
Cela impliquerait de créer un moteur de test adaptatif qui peut apprendre au fur et à mesure, en développant une connaissance plus approfondie du comportement de l’API afin de rétro-concevoir intelligemment son fonctionnement interne caché. En utilisant les données d’exécution et les informations de logique métier, vous pouvez profiter du meilleur des deux mondes – l’approche boîte noire et blanche pour une visibilité et un contrôle améliorés grâce à l’automatisation.
Envelopper
En plus de leur popularité croissante, les API créent également une plus grande vulnérabilité pour les applications Web. Un grand nombre d’organisations ne connaissent même pas l’étendue de leurs API et de leurs vulnérabilités. Les faiblesses connues et inconnues peuvent facilement être sondées par les pirates via les API disponibles.
Cependant, les tests de sécurité des API sont souvent négligés et gérés de la même manière que les applications Web. La plupart des approches de test, telles que les tests en boîte noire et en boîte blanche, ne sont pas propices aux tests d’API.
Une combinaison de traitement du langage naturel et d’intelligence artificielle (IA) offre une option viable de « boîte grise » qui automatise, met à l’échelle et simplifie le processus complexe de test de sécurité des API.
