Application vs. Sécurité des API ? Les robots s'en moquent. Protégez vos actifs numériques
C'est l'heure du quiz surprise. Lequel de ces points de terminaison appartient à une API et lequel appartient à une application ?
https://www.example.com/product
https://www.example.com/product
Si vous êtes confus et n’arrivez pas à vous décider, ce n’est pas grave. C’est là le problème. Les points de terminaison des applications et des API se ressemblent beaucoup. C’est parce qu’en termes techniques, s’ils sont RESTful (et la plupart le sont), ils sont invoqués de la même manière, via HTTPS et généralement avec une méthode GET. Ce qui est souvent différent, c’est la charge utile envoyée avec la requête. Pour les API qui contiennent généralement des données au format JSON ou XML, tandis que les requêtes d'applications Web peuvent ne contenir, eh bien, rien.
Cependant, l’une des principales conclusions de notre recherche annuelle implique que les organisations traitent les API différemment des applications en matière de sécurité. Nous en déduisons cela du constat selon lequel 41 % des organisations disposent d’au moins le même nombre , voire d’un nombre supérieur , d’API que d’applications, et accordent pourtant une valeur moindre aux mêmes services de sécurité qui les protègent.
Vous vous demandez peut-être comment les organisations pourraient se retrouver avec plus d’API que d’applications. Merci d'avoir demandé ! Bien que les API utilisées pour la communication interne de service à service (à la manière des microservices) soient certainement étroitement liées au service qu'elles prennent en charge, ce n'est pas nécessairement vrai lorsque les API sont utilisées pour présenter des interfaces externes.
D'où viennent les API ?
Considérez que dans notre étude de 2021, 61 % des répondants nous ont dit qu’ils « ajoutaient une couche d’API pour permettre des interfaces utilisateur modernes » comme méthode de modernisation. En 2022, ce chiffre était de 45 %. Cela signifie que les API qui permettent les interfaces utilisateur modernes ne sont pas nécessairement des artefacts directement attachés aux applications. Il peut s'agir de façades facilitant les interfaces utilisateur et les applications modernes, comme les applications mobiles et les services numériques , ou de façades conçues pour permettre les communications entre partenaires et la chaîne d'approvisionnement. Ces cas d'utilisation sont pris en charge par les passerelles API et le routage de couche 7 dans les équilibreurs de charge, qui fournissent souvent un certain niveau de capacités de transformation qui leur permettent de passer du point de terminaison API au point de terminaison d'application, permettant ainsi une façade API comme celles qui font que les anciens bâtiments de l'ouest américain semblent beaucoup plus impressionnants qu'ils ne le sont.
Et bien sûr, un bon nombre d’API sont des entités publiques attachées à des applications et accessibles via le Web (généralement HTTPS).
Quelle que soit la manière dont elles y sont parvenues, les API publiques sont soumises à bon nombre des mêmes attaques que les applications. Cela est particulièrement vrai lorsque des robots sont impliqués, car les API avec une bonne documentation permettent simplement aux attaquants de créer facilement des scripts d'attaques à grande échelle.
Par exemple, un peu plus de 13 % des transactions protégées par F5 Distributed Cloud Bot Defense en 2023 ont été automatisées. Autrement dit, un script ou un logiciel a été utilisé à la place d'un humain utilisant un navigateur Web ou une application mobile. Ces transactions se font via des API et des applications. Un certain pourcentage de ces transactions automatisées étaient certainement des « mauvais robots » que la présence de notre service de sécurité empêchait de faire ce qu’ils essayaient de faire. (Vous pouvez approfondir ce qu'ils essayaient de faire dans ce rapport de F5 Labs )
Ainsi, lorsque nous avons examiné la façon dont les répondants perçoivent la gestion des robots en fonction du nombre d’API qu’ils ont eux-mêmes déclaré, nous avons été quelque peu choqués de découvrir que la gestion des robots est assez faible sur l’échelle d’importance.
Vous pouvez voir à partir de ces graphiques à barres astucieux que si l’importance accordée aux passerelles API semble appropriée au nombre d’API sous gestion, il n’en va pas de même pour la gestion des robots. En fait, c’est tout le contraire ! À mesure que le nombre d’API augmente, l’importance de la gestion des robots semble diminuer. Rapidement.
Il se pourrait certainement que la majeure partie de ces API soient internes. Autrement dit, il s’agit d’API est-ouest entre des microservices qui ne sont pas exposés à des acteurs externes qui pourraient être des robots malveillants.
Mais bon, c’est peut-être le cas. Étant donné le nombre d’articles que j’ai lus au cours de l’année écoulée sur les attaquants accédant aux données via des API, je suppose qu’il y en a beaucoup plus d’externes que nous le pensons.
Il est donc temps de rappeler aux gens que s’il existe un certain nombre de robots ennuyeux (bots Grinch, robots baskets, etc.) qui perturbent les affaires en engloutissant des biens très demandés, il existe également un nombre important de robots dont le seul but est de détecter les vulnérabilités et de les attaquer. Dans les API comme dans les applications.
Il serait donc judicieux pour les organisations d’utiliser une gamme complète d’options de sécurité pour protéger leurs API et, en fin de compte, leur activité. La gestion des robots est certainement l’une de ces options de sécurité et doit être considérée comme un élément essentiel de toute stratégie de sécurité.
En fin de compte, les robots ne se soucient pas de savoir si ce point de terminaison appartient à une application ou à une API. Ils vont attaquer les deux.
Cela signifie que les organisations doivent protéger à la fois les applications et les API en détectant les robots et en les empêchant de faire tout ce qu'ils tentent de faire.
Vous voulez voir la défense des robots en action, regardez cette démo .