Solutions de sécurité des API

Les API sont uniques du fait de nombreuses caractéristiques. Elles échangent des données entre les systèmes, par exemple, alors que les utilisateurs finaux accèdent aux applications web par l'intermédiaire d'un navigateur web. Les API utilisent un format différent pour transporter les données et accèdent directement aux systèmes back-end. Elles servent souvent d'intermédiaire entre les applications web modernes et leurs bases de données/serveurs back-end. Du fait de ces différences (et des autres), la méthodologie de détection utilisée pour la sécurité des API diffère de celle de la sécurité des applications web, même pour les catégories de vulnérabilités communes, comme les attaques par injection et les risques liés aux accès.

Un certain nombre d'approches permettent aux entreprises modernes de gérer l'ensemble de leurs API : la gestion de l'intégralité du cycle de vie des API, l'observabilité des API et, de manière plus globale, la protection des API et des applications web (Web Application And Protection, WAAP). Les outils d'observabilité des API fournissent des observations et des statistiques (plutôt qu'une sécurité) concernant les performances d'une API. La gestion de l'ensemble du cycle de vie des API se concentre souvent sur la gestion des API elles-mêmes, tout en manquant de fonctionnalités de sécurité sophistiquées. La protection des API et des applications web (WAAP) est définie par Gartner comme une catégorie de solutions de sécurité conçues pour protéger les applications web, indépendamment de l'endroit où elles sont hébergées. L'approche WAAP convient mieux aux API en production, à la surveillance en temps réel, ainsi qu'à la protection contre les abus, les menaces zero-day et les acteurs malveillants.

Les API REST permettent à un client de demander des ressources à un serveur, qui renvoie l'information au client dans son état actuel. Les acteurs malveillants peuvent prendre l'API pour cible à n'importe quel point du cycle « d'appel et de réponse » de l'API REST. Par conséquent, pour empêcher les abus vis-à-vis des API REST, il est nécessaire de n'autoriser que le trafic d'API « utile » et authentifiée, de manière à bloquer les requêtes provenant de clients illégitimes. Les certificats mTLS, les JSON Web Tokens, les clés d'API valides et les jetons OAuth 2.0 ne sont que quelques exemples de méthodes d'authentification et d'autorisation des API.

Les clés d'accès aux API, qui détachent l'authentification des identifiants utilisateur et envoie à la place des chaînes textuelles secrètes en même temps que les requêtes d'API, permettent un accès plus sécurisé aux API. Toutefois, les clés d'API font toujours face aux risques posés par les attaques de l'homme du milieu (man-in-the-middle), l'utilisation incorrecte des ressources pour développeurs et le problème du stockage des secrets au sein du code source. Les JSON Web Tokens (JWT, jetons web JSON) proposent une alternative plus sécurisée et plus flexible aux clés d'API statiques, tant que les JWT sont signés à l'aide d'algorithmes cryptographiques sécurisés, qui évitent la présence de données sensibles dans le contenu et font respecter l'expiration des jetons.

Les parties prenantes en matière d'informatique, de sécurité et de développement d'applications peuvent s'appuyer sur différents indicateurs pour évaluer le niveau de sécurité de leurs API. Une entreprise dotée d'un robuste modèle de sécurité des API doit, par exemple, disposer d'un inventaire à jour des ressources API montrant que toutes ses API sont conformes aux réglementations sur les données et utiliser des méthodes fortes pour l'authentification ou l'autorisation. Elle doit également réaliser des audits afin d'identifier les identifiants exposés (ou ayant fait l'objet d'une fuite) utilisés dans les requêtes d'API et analyser les requêtes/réponses d'API à la recherche d'informations d'identification personnelle (PII), de données de cartes de paiement et d'informations personnelles liées à la santé. La capacité à définir des mesures de contrôle du volume adaptatives et intelligentes pour les API, telles que déterminées par les schémas de trafic observables pour chaque point de terminaison, témoigne également d'une sécurité des API plus avancée.

L'expression « abus d'API » se réfère à l'utilisation malveillante des API permise par l'exploitation des défauts de la logique métier et des vulnérabilités des applications afin de bloquer ou de dégrader l'expérience d'un utilisateur réel. Le plus souvent, les API d'aujourd'hui sont confrontées à divers problèmes (exposition de données, actions non autorisées, contournement des mesures de sécurité, perturbation de service et élévation des privilèges) du fait de l'absence de mesures de contrôle de l'authentification et de l'autorisation, un phénomène connu sous le nom de Broken Object Level Authorization (BOLA, violation de l'autorisation au niveau de l'objet) et de Broken Function Level Authorization (BFLA, violation de l'autorisation au niveau de la fonction).