4 croyances qui nuisent à une protection efficace des API
This post is also available in:
Anglais 
Allemand 
Italien 
Portugais - du Brésil 
Espagnol
Ce n’est un secret pour personne : les applications modernes interagissent avec leurs différents composants, leurs utilisateurs et parfois avec des services externes via des API. L’utilisation de ces API a explosé en 2021. Selon une étude de marché, le trafic généré par des attaques sur des API a triplé proportionnellement au trafic global généré par les API. Pour couronner le tout, Gartner estime qu’en 2021, plus de 50 % de tous les incidents de vol de données pourront être reliés à des API non sécurisées.
Dans ces conditions, pourquoi la protection des API n’a-t-elle pas suivi l’évolution de leur utilisation ? D’après ce que les entreprises nous rapportent au sujet de leurs stratégies de protection des API, il semble qu’un grand nombre d’entre elles se fient à de fausses croyances qui rendent leurs API vulnérables et exposées aux menaces.
Croyance n° 1 Mon WAF protège mes applications et leurs API
Si cette affirmation est en partie fondée, les API sont quand même exposées à de nombreux vecteurs de menace contre lesquels la plupart des pare-feu applicatifs web (WAF) ne peuvent rien.
Tout d’abord, la plupart des solutions WAF sont conçues pour protéger les vulnérabilités des applications web. Les API, quant à elles, requièrent un traitement particulier, tel que l’analyse de leur contenu et sa comparaison au schéma spécifique de l’API. Les WAF standard ne disposent généralement pas de ce type de fonctionnalités.
Ensuite, la plupart des solutions WAF (notamment les services managés de WAF cloud) ne déploient que des modèles de sécurité négatifs. Cela limite la capacité des solutions à fournir une protection contre les attaques de type « zero-day », qui sont des attaques encore inconnues pour lesquelles il n’existe pas de signature. La liste de l’OWASP des 10 principaux vecteurs de menace pour les API comprend de nombreux types d’attaques qui ne peuvent tout simplement pas être couverts par un modèle de sécurité négatif. Ces vecteurs rendent nécessaires un modèle de sécurité positif et une analyse comportementale permettant de déterminer si l’appel d’API est malveillant ou non (une fonction que la plupart des WAF ne possèdent pas).
Enfin, certaines menaces automatisées, notamment les mauvais bots, peuvent également poser de gros problèmes aux API. Comment distinguer un mauvais bot d’un appel légitime machine à machine ? Des solutions avancées de gestion des bots capables d’analyser les appels d’API sont nécessaires pour se protéger contre les attaques de mauvais bots, telles que la prise de contrôle de comptes, le <i>data scraping</i> et d’autres types d’attaques DoS sur les applications. À l’heure actuelle, aucun WAF ne propose cette fonctionnalité.
[Sur le même thème :Protection des applications – 5 pièges courants
Croyance n° 2 Ma passerelle d’API gère et protège mes API
Les passerelles d’API sont conçues pour gérer le cycle de vie des API, traduire les protocoles, acheminer les appels d’API vers la bonne destination et gérer les quotas de manière à ce que les ressources du serveur traitant les appels d’API ne soient pas épuisées ni utilisées de manière frauduleuse.
Les passerelles d’API permettent également d’authentifier l’entité qui effectue l’appel d’API afin de vérifier qu’elle a l’autorisation d’exécuter chaque appel spécifique. Certaines passerelles d’API intègrent aussi un moteur basé sur les signatures qui offre une protection supplémentaire aux appels d’API qu’elles traitent. Si toutes ces fonctions sont très utiles, elles ne suffisent pas à assurer une protection efficace des API. Il n’existe à ce jour aucune solution de passerelle d’API incluant une protection des API avec moteur basé sur un modèle de sécurité positif, des capacités de protection contre les bots, l’analyse comportementale et la protection contre les attaques DoS applicatives.
Saviez-vous que tous les appels d’API étaient centralisés et passaient par des passerelles d’API ? Ceci ne concerne que les API connues et managées. En conséquence, dans de nombreuses entreprises, un grand nombre d’API non documentées et non managées ne sont pas prises en compte, et il est impossible de protéger ce dont vous ignorez l’existence.
Par ailleurs, la plupart des passerelles d’API comportent des <i>hooks</i> permettant l’intégration de solutions tierces de protection des API. Ceci est un aveu de la part des vendeurs d’API, qui connaissent les limites de leur passerelle d’API en matière de protection des API qu’elles gèrent.
Croyance n° 3 Mes API sont bien documentées, ce qui garantit une protection efficace
Effectivement, pour protéger efficacement une API, il faut connaître intimement sa structure, ses paramètres possibles, le type et la plage des valeurs, ainsi que le contenu escompté pour le corps de l’API. Si vos API sont bien documentées et que vous disposez d’une solution qui les protège correctement, votre sécurité s’en trouve considérablement renforcée.
Mais, le plus souvent, toutes les API utilisées dans l’entreprise ne sont pas documentées. Et même si elles le sont, elles changent plus fréquemment que les applications. Il faut donc mettre à jour régulièrement leur documentation et leur politique de sécurité, une tâche qui n’est pas effectuée aussi régulièrement que nécessaire. D’ailleurs, la plupart des architectes sécurité ne font pas confiance à la documentation des API.
Une solution de protection efficace des API doit inclure une fonction de découverte automatique des API. Une telle fonction consiste non seulement à découvrir quelles API sont en place, mais aussi leur structure (c’est-à-dire leur schéma), leurs paramètres, le type de ces paramètres et leurs plages de valeurs. Un bon moteur de découverte est également capable de générer et d’appliquer automatiquement une politique de sécurité adaptée aux API découvertes afin de les protéger efficacement. Il s’agit de la meilleure façon de protéger efficacement une API tout au long de son cycle de vie.
[Sur le même thème :Comment assurer la protection des applications derrière AWS/Azure CDN]
Croyance n° 4 J’ai une solution de protection des API dédiée, je suis donc protégé
Une bonne protection des API satisfaisant les recommandations mentionnées dans ce blog est un bon début. Mais elle n’est que cela – un début – et cela ne suffit pas à protéger complètement votre application. Les API ne sont pas des entités autonomes. Elles font partie d’une application. L’application est déployée dans une infrastructure. Des pirates qui ne parviendraient pas à pénétrer votre réseau par le biais des API chercheront à s’introduire via une vulnérabilité de l’application sans rapport avec l’API. Ils pourront lancer une attaque de bots ou simplement déclencher une attaque DDoS sur l’infrastructure.
La protection des applications doit être envisagée de manière holistique, ce qui signifie que tous les aspects doivent être pris en compte. Votre protection est seulement aussi robuste que son maillon le plus faible.
La protection des API n’est que l’une des composantes importantes de votre architecture globale de protection des applications, qui doit également comprendre un solide WAF, une capacité de gestion des bots, des renseignements sur les menaces et une protection contre les attaques DDoS. Si vous pouvez gérer toutes ces composantes depuis un seul et même écran et les synchroniser, vos applications et vos API seront efficacement protégées.
Souhaitez-vous en savoir plus ? Assistez à notre webinaire, nous vous informerons plus amplement sur les bonnes pratiques permettant de combler les lacunes de protection évoquées dans ce blog.
