Alors que les entreprises d’aujourd’hui fournissent régulièrement des API à leurs applications internes, leur permettant de communiquer avec d’autres logiciels, ces interfaces présentent parfois des failles de sécurité qui mettent en danger les données sensibles. Dans le pire des cas, ils ouvrent la porte à des attaques API qui pourraient entraîner des violations de données catastrophiques.
Certains des principaux risques liés aux API proviennent de la publication d’API, tandis que d’autres proviennent de la consommation d’API pour les intégrer à des systèmes ailleurs.
Risques liés à la publication d’API
Examinons certaines vulnérabilités et risques des API, en commençant par ceux basés sur la publication des API, ainsi que les mesures de sécurité qui peuvent aider à les atténuer.
Authentification mauvaise ou faible
Pour que leur utilisation soit sûre, même en interne, les API doivent utiliser des mécanismes d’authentification pour garantir que l’entité qui leur demande de faire quelque chose est bien ce qu’elle prétend être et qu’elle est connectée aux personnes ou institutions qu’elle prétend être.
Malheureusement, lors du développement d’API, les codeurs échouent trop souvent à mettre en œuvre une authentification forte et actuelle. Par conséquent, comme d’autres applications Web, les back-ends des API sont souvent confrontés à une authentification faible que les pirates malveillants peuvent facilement compromettre ou à une authentification brisée qu’ils peuvent contourner.
Lorsque l’API ne parvient pas à établir correctement l’identité de l’entité à l’autre bout de l’appel API, l’entreprise risque d’effectuer des actions, de partager des informations sensibles ou d’accepter des entrées de personnes ou de systèmes qu’elle n’a pas l’intention de faire.
Atténuation
Suivez des méthodologies de développement sécurisées. Les codeurs doivent standardiser les modules d’authentification forte et utiliser des tests automatisés pendant les cycles de développement qui rejettent tout code avec une authentification non standard.
L’équipe de cybersécurité doit également effectuer des tests d’intrusion sur les API, à la recherche d’une authentification inadéquate.
Savoir d’où proviennent les requêtes API ne représente que la moitié de la bataille. L’autre moitié contrôle correctement l’accès aux systèmes back-end et aux données en fonction de cette identité.
Mauvaise autorisation
Savoir d’où proviennent les requêtes API ne représente que la moitié de la bataille. L’autre moitié contrôle correctement l’accès aux systèmes back-end et aux données en fonction de cette identité. Ici, les problèmes tournent autour des droits d’accès : soit ils sont inadéquats, soit ils sont trop généreux.
Un accès inadéquat aux API peut empêcher tout accès non autorisé, mais laisse les partenaires ou clients légitimes sans autorisation pour récupérer les données et les services dont ils ont besoin pour fonctionner correctement.
À l’autre extrémité du spectre, un contrôle d’accès trop étendu permet aux utilisateurs de voir ou de faire des choses au-delà de ce dont ils ont besoin et pourrait permettre à des acteurs malveillants d’accéder à des informations et à des systèmes privés.
Atténuation
Les tests d’acceptation complets des utilisateurs – automatisés si possible – doivent reproduire des scénarios d’accès réels.
L’objectif est d’évaluer la capacité de l’API à accorder à une requête correctement authentifiée l’accès à toutes les données nécessaires, à partir des objets ou des magasins de données qui la contrôlent. Ces tests de sécurité doivent également inclure des demandes de récupération de données ou d’exécution d’actions pour lesquelles les comptes de test ne sont pas autorisés. Il s’agit de garantir qu’ils échouent de la manière attendue.
Les entreprises qui publient des API doivent ajouter des examens d’API à leurs audits globaux de politique d’authentification. Et ils devraient tester le respect de ces politiques dans le cadre de leurs tests d’intrusion réguliers.
Attaques par déni de service
En tant que services orientés réseau, les API peuvent être soumises à des attaques DoS et DDoS conçues pour les submerger d’un faux trafic. Si les API fournissent des services nécessaires à l’entreprise, leur sous-performance ou leur manque de disponibilité pourrait avoir de graves conséquences pour l’entreprise.
Les attaques DoS ou DDoS pourraient empêcher les API de répondre aux demandes légitimes en temps opportun. Ou bien des requêtes mal formées pourraient les amener à consommer des ressources sans les libérer, les épuisant ainsi. Enfin, ils peuvent simplement être poussés au point où le processus de l’API plante.
Atténuation
Mettez en file d’attente et limitez les demandes avant qu’elles n’atteignent les systèmes back-end. Envisagez également de mettre en œuvre des défenses DDoS et un codage plus strict pour éviter les problèmes de « demande suspendue ».
Falsification de requête côté serveur
Parmi les principaux risques liés aux API figure la falsification de requêtes côté serveur. Les SSRF transforment le service API en une dupe involontaire d’un mauvais acteur, créant ainsi le risque d’une compromission latérale ou de devenir complice d’attaques contre d’autres.
En soumettant une requête soigneusement construite via l’API, l’acteur malveillant cherche à ce que le service API atteigne un autre système au sein de l’infrastructure ou une ressource ou un site tiers. Par exemple, un appel API s’attendant à recevoir une URL pour la page LinkedIn d’une personne pourrait plutôt recevoir une demande d’ouverture d’un port TCP sur le propre hôte du service API.
Atténuation
Limitez le type et la portée des URL valides sur les entrées afin qu’elles puissent faire uniquement ce qui est prévu. Utilisez un analyseur actuel sur les URL pour vous assurer qu’elles sont bien formées et du type attendu. Utilisez une liste verte pour contrôler où les URL peuvent pointer.
Le service informatique doit également mettre en œuvre le modèle Zero Trust dans l’environnement API pour empêcher les services d’atteindre latéralement des systèmes avec lesquels ils ne devraient pas communiquer. Notez qu’il s’agit d’un exemple d’un risque plus large : une vérification insuffisante des entrées provenant des requêtes API.
Entrées malveillantes
Les gestionnaires d’API peuvent, et le font trop souvent, accepter naïvement les entrées des utilisateurs et les cacher dans des structures de données dans le code ou dans des bases de données externes sans les vérifier au préalable. Comme pour les applications Web, il s’agit du vecteur classique des attaques par injection SQL, des attaques par débordement de tampon, des SSRF et bien plus encore.
Les API sont confrontées au même risque que des données fausses ou absurdes soient considérées comme valides. Si cela se produit, le gestionnaire d’API pourrait devenir la plate-forme d’une sorte d’attaque latérale contre des cibles internes ou d’une attaque réfléchie contre des cibles externes.
Atténuation
N’acceptez jamais les commentaires bruts du demandeur. Analysez et validez toujours les entrées.
Partage excessif de données
Les API exposent parfois plus de données que ce que la politique de sécurité des données de l’entreprise prévoit. Cela crée le risque que des informations personnelles identifiables ou d’autres informations protégées soient révélées de manière inappropriée.
Une exposition excessive des données peut résulter de la création et du test d’API sur un extrait d’un ensemble de données, mais de la diffusion du code sur un ensemble de données plus large en production. Cela peut également être le résultat de problèmes d’authentification (voir ci-dessus).
Atténuation
Testez sur des ensembles de données qui limitent le nombre d’enregistrements mais pas les types ou les champs contenus afin de valider plus précisément l’accès. Utilisez des systèmes de prévention contre la perte de données pour surveiller et alerter, bloquer ou supprimer activement les données qui ne devraient pas être révélées de cette manière.
Lorsque les processus internes dépendent des mêmes services API que les intégrations externes, les processus métier de l’entreprise sont exposés aux interférences des utilisateurs de l’API. Les attaques DoS axées sur les API peuvent paralyser les processus internes (et pas seulement ceux externes) et entraver sérieusement la capacité de l’organisation à faire des affaires.
Atténuation
Séparez les services d’API internes de ceux externes pour empêcher les attaques sur les API externes d’affecter directement les API internes.
Sources de risques supplémentaires liées aux API
Les autres sources de risques courantes pour les entreprises publiant des API sont les suivantes :
Contrôle de version inadéquat des services sous-jacents aux API, entraînant des inadéquations au niveau de l’authentification, de l’autorisation et de l’analyse des entrées.
Journalisation manquante ou inadéquate de l’activité de l’API et surveillance des journaux.
Risques liés à la consommation d’API
Les risques liés aux API ne se limitent pas à la publication ; Tenez compte des risques suivants liés à la consommation des API.
Consommation dangereuse de données
Lorsqu’une organisation utilise des API pour récupérer des données à partir de systèmes situés ailleurs, cela crée un risque que ces données soient mauvaises, voire malveillantes. Cela peut conduire l’organisation à prendre de mauvaises décisions et à prendre des mesures incorrectes ou à signaler des mensonges plutôt que des faits aux régulateurs, aux clients ou aux partenaires.
Atténuation
La validation des entrées est essentielle pour sécuriser les API. Gardez une trace de la provenance des données afin que les problèmes puissent être correctement attribués et étudiés.
Risque tiers non documenté
Les entreprises s’exposent à des problèmes lorsqu’elles assument des risques liés à des tiers, essentiellement des risques provenant des fournisseurs de leurs fournisseurs.
Il y a tellement d’API qui consomment d’autres API tierces – qui peuvent encore consommer d’autres API, etc. – qu’il peut être difficile de savoir combien d’entités différentes pourraient finalement être impliquées dans la réponse à une demande d’API. Cela peut entraîner une vaste surface d’attaque.
Atténuation
Contrôlez votre écosystème d’API en limitant le nombre d’autres API que vos propres API utilisent. Recherchez des accords contractuels avec ces autres fournisseurs d’API pour définir et limiter votre risque tiers.
Risque non documenté pour les processus métier
Lorsque les processus métier dépendent de la consommation des API mais que cette dépendance n’est pas documentée, il est trop facile pour le processus de s’interrompre.
Les modifications apportées au processus métier peuvent être apportées sans tenir compte du fait qu’elles nécessitent des modifications dans la façon dont l’API est utilisée, ce qui entraîne par exemple un fonctionnement incorrect du processus. Ou encore, les modifications apportées au fonctionnement de l’API peuvent entraîner des changements subtils dans son comportement, problématiques mais pas immédiatement apparents.
Atténuation
Documentez soigneusement tous les processus commerciaux. Utilisez des architectures Zero Trust pour empêcher les systèmes internes d’accéder aux API internes ou externes sans autorisation explicite de le faire.
Les risques inhérents aux API ne sont pas propres aux API. Pour gérer les principaux risques liés aux API et garantir la sécurité du réseau de l’organisation, les systèmes informatiques et de cybersécurité doivent être familiers avec les types de problèmes à l’origine de ces risques, ainsi qu’avec les outils et les stratégies conçus pour atténuer ces dangers.
John Burke est CTO et analyste de recherche principal chez Nemertes Research. Avec près de deux décennies d’expérience technologique, il a travaillé à tous les niveaux de l’informatique, notamment spécialiste du support utilisateur final, programmeur, administrateur système, spécialiste des bases de données, administrateur réseau, architecte réseau et architecte système. Ses domaines d’intervention comprennent l’IA, le cloud, les réseaux, les infrastructures, l’automatisation et la cybersécurité.
