Recette pour un désastre : Stratégies axées sur l'API et la sécurité en dernier
La demande d’API augmente. Qu'il s'agisse de contribuer à alimenter l'économie numérique en permettant le développement d'applications mobiles ou d'augmenter la productivité en interne grâce à des initiatives d'automatisation et d'orchestration, les API sont partout.
De nombreuses organisations ont adopté le cri de ralliement numérique « API first ! À savoir, une majorité (60 %) des répondants à l' étude State of API Integration 2018 de Cloud Elements mettent une API à la disposition de n'importe quel développeur. Cela porte ses fruits. Pas moins de 85 % des organisations génèrent au moins une partie de leurs revenus à partir des API et des implémentations liées aux API. La majorité (59 %) génèrent entre 11 et 50 % des revenus de leur organisation. Plus d’une entreprise sur dix (11 %) génère plus de la moitié de ses revenus uniquement à partir des API. ( La valeur croissante des API de MuleSoft )
Mais laissez-moi vous rappeler qu’ils rendent leurs API ouvertes à TOUS les développeurs. Pas n’importe quel développeur bien intentionné, mais n’importe quel développeur.
La nature ouverte de l’économie des API d’aujourd’hui est l’une des raisons pour lesquelles il est regrettable qu’une stratégie privilégiant les API soit trop souvent accompagnée d’une stratégie privilégiant la sécurité.
Une véritable corne d’abondance d’incidents de sécurité liés aux API impliquant des organisations de premier plan peut être trouvée avec une relative facilité. Qu'elles soient mentionnées par Forbes ou découvertes par nos propres laboratoires F5 , ces organisations ont subi des failles de sécurité liées aux API qui auraient pu être évitées grâce à des pratiques et des outils de sécurité bien compris .
Notre propre Ray Pompon, principal évangéliste en recherche sur les menaces pour F5 Labs, a noté dans ses recherches sur la sécurité des API :
« … vous pouvez voir des modèles associés aux mêmes problèmes classiques de sécurité des applications que nous avons toujours rencontrés : des attaquants obtenant un accès par des attaques par force brute ou des informations d'identification volées. De plus, une fois authentifiés auprès de l'API, les attaquants ont exploité les autorisations attribuées trop larges.
Extrait de < https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents >
Les mêmes problèmes classiques. Parce qu’en fin de compte, les API sont le plus souvent implémentées sous forme d’URI transportés via HTTP transportant une charge utile de données JSON ou XML. Ce qui n’est pas si différent d’une URI transportée via HTTP transportant une charge utile de données de formulaire POSTées.
Et n’oublions pas qu’une API n’est qu’une interface pour coder. Code qui, selon les statistiques de sécurité des applications WhiteHat , présente en moyenne 39 vulnérabilités pour 100 000 lignes de code (LOC). Attendez, c'est pour une application traditionnelle. Que diriez-vous de 180 pour 100 000 LOC si vous avez implémenté l' interface (API) à l'aide d'une architecture de microservices. Quoi qu’il en soit, cela représente beaucoup de vulnérabilités.
Une API comporte les mêmes vulnérabilités que son homologue, l'application Web. Elle nécessite donc la même attention en matière de sécurité qu'une application Web.
Et pourtant, l’importance accordée à la sécurité des API n’est pas à la hauteur de celle des applications Web d’aujourd’hui – du moins pas sur la base de preuves existentielles exposant l’approche médiocre des tests de sécurité effectués. Un sondage informel réalisé par SmartBear a révélé que seulement 12 % des personnes interrogées ont effectué aujourd'hui des tests de sécurité des API « approfondis ». Près du double - 23 % pour être exact - n'ont effectué AUCUN TEST DE SÉCURITÉ API. Cela correspond à une recherche plus formelle menée par SmartBear qui a révélé que 80 % des répondants testent leurs API.
Il reste encore 20 % qui ne le font pas.
API-first est un excellent moyen de s’engager dans l’économie numérique et de transformer à la fois les entreprises et les opérations en machines numériques légères et efficaces. Mais mettre la sécurité en dernier est un excellent moyen de transformer cela en un hashtag tendance et amer sur Twitter*. Et personne ne veut ça.
Donc, si vous envisagez d'adopter l'approche API-first (et vous devriez le faire), vous devez faire de la sécurité une priorité absolue. N'acceptez pas une stratégie privilégiant la sécurité pour vos API.
Quelques étapes simples pour vous aider à démarrer :
- S'il existe, testez-le.
- S'il y a une contribution de l'utilisateur, ne lui faites pas confiance.
- S'il existe une connexion utilisateur, protégez-la contre les attaques par force brute et par vol d'informations d'identification.
- Soyez conscient de la nécessité de maintenir et de corriger les systèmes et services sur lesquels repose votre API. Leur vulnérabilité est la vulnérabilité de votre API.
Restez en sécurité là-bas.