Principaux risques liés aux API et moyens de les atténuer

Risques liés à la publication d'API

Examinons quelques vulnérabilités et risques liés aux API, en commençant par ceux basés sur la publication des API, et les mesures de sécurité qui peuvent contribuer à les atténuer.

Authentification mauvaise ou faible

Pour pouvoir être utilisées en toute sécurité, même en interne, les API doivent utiliser des mécanismes d'authentification afin de s'assurer que l'entité qui leur demande de faire quelque chose est bien celle qu'elle prétend être et qu'elle est reliée aux personnes ou aux institutions qu'elle prétend être.

Malheureusement, lors du développement d'API, les codeurs omettent trop souvent de mettre en œuvre une authentification robuste. Par conséquent, à l'instar des autres applications web, les back ends des API sont souvent truffés de mécanismes d'authentification faibles que les pirates malveillants peuvent facilement compromettre ou de mécanismes mal implémentés qu'ils peuvent contourner.

Lorsque l'API ne peut 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 données provenant de personnes ou de systèmes qu'elle n'a pas l'intention d'utiliser.

Atténuation

Suivre des méthodologies de développement sécurisées. Les codeurs devraient standardiser les modules d'authentification forte et utiliser des tests automatisés pendant les cycles de développement qui rejettent tout code dont l'authentification n'est pas standard.

L'équipe de cybersécurité doit également effectuer des tests d'intrusion des API, à la recherche de mécanismes d'authentification inadéquates.

Mauvaises autorisations

Savoir d'où viennent les demandes d'API n'est que la moitié de la bataille. L'autre moitié consiste à contrôler correctement l'accès aux systèmes dorsaux et aux données en fonction de cette identité. Ici, les problèmes sont centrés sur les droits d'accès - qu'ils soient inadéquats ou trop généreux.

Un accès inadéquat à l'API peut empêcher un accès non autorisé, mais laisse les partenaires ou les 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 large permet aux utilisateurs de voir ou de faire des choses au-delà de ce qui est nécessaire et pourrait permettre à des acteurs malveillants d'accéder à des informations et à des systèmes privés.

Atténuation

Les tests d'autorisation suivant l'utilisateur, si possible automatisés, doivent reproduire des scénarios d'accès réels.

L'objectif est d'évaluer la capacité de l'API à accorder à une demande correctement authentifiée l'accès à toutes les données nécessaires, quels que soient les objets ou les magasins de données qui les contrôlent. Ces tests de sécurité doivent également inclure des demandes d'extraction de données ou d'exécution d'actions pour lesquelles les comptes de test ne sont pas autorisés. Cela permet de s'assurer qu'elles échouent de la manière attendue.

Les entreprises qui publient des API devraient ajouter des examens d'API à leurs audits généraux de politique d'authentification. Elles devraient également vérifier la conformité à ces politiques dans le cadre de leurs tests d'intrusion réguliers.

Attaques en déni de service

En tant que services orientés vers le réseau, les API peuvent faire l'objet d'attaques DoS et DDoS visant à les submerger de faux trafic. Si les API fournissent des services nécessaires à l'activité de l'entreprise, leurs performances insuffisantes ou leur manque de disponibilité peuvent avoir de graves conséquences pour l'entreprise.

Les attaques DoS ou DDoS peuvent signifier que les API ne sont pas en mesure de répondre aux demandes légitimes en temps voulu. Ou encore, des demandes mal formées peuvent les amener à consommer des ressources sans les libérer, ce qui les épuise. Enfin, elles peuvent simplement être poussées au point que le processus de l'API s'arrête.

Atténuation

Mettez les demandes en file d'attente et limitez leur rythme avant qu'elles n'atteignent les systèmes dorsaux. Envisagez également de mettre en place des défenses contre les attaques DDoS et un codage plus strict pour éviter les problèmes de demandes en suspens.

Falsification des requêtes côté serveur

L'un des principaux risques liés aux API est la falsification des requêtes côté serveur. Les SSRF (ou Server-Side Request Forgery) transforment le service API en un dupe involontaire d'un acteur malveillant, créant ainsi le risque d'une compromission latérale ou de devenir complice d'attaques contre d'autres personnes.

En soumettant une demande soigneusement élaborée via l'API, l'acteur malveillant cherche à amener le service API à atteindre un autre système au sein de l'infrastructure ou une ressource ou un site tiers. Par exemple, un appel à l'API s'attendant à recevoir l'URL de la page LinkedIn d'une personne peut être remplacé par une demande d'ouverture d'un port TCP sur l'hôte du service API.

Atténuation

Limiter le type et la portée des URL valides en entrée afin qu'ils ne fassent que ce qui est prévu. Utiliser un analyseur syntaxique parcourant les URL pour s'assurer qu'ils sont bien formés et du type attendu. Utiliser une liste d'autorisations pour contrôler où les URL peuvent pointer.

Les services informatiques devraient également mettre en œuvre une approche sans confiance dans l'environnement API afin d'empêcher les services d'atteindre latéralement des systèmes avec lesquels ils ne devraient pas communiquer. Il convient de noter qu'il s'agit d'un exemple d'un risque plus large, à savoir le contrôle insuffisant des entrées provenant des demandes d'API.

Entrées malveillantes

Les gestionnaires d'API peuvent, et c'est trop souvent le cas, accepter naïvement les données de l'utilisateur et les stocker dans des structures de données dans le code ou dans des bases de données externes sans les avoir vérifiées au préalable. Comme pour les applications web, il s'agit d'un vecteur classique pour les attaques par injection SQL, les attaques par débordement de mémoire tampon, les SSRF, etc.

Les API courent le même risque que des données fausses ou absurdes soient traitées comme valides. Dans ce cas, le gestionnaire de l'API peut devenir la plateforme d'une attaque latérale sur des cibles internes ou d'une attaque réfléchie sur des cibles externes.

Atténuation

N'acceptez jamais d'entrées brutes de la part du demandeur. Toujours analyser et valider les entrées.

Partage excessif de données

Les API exposent parfois plus de données que ne le prévoit la politique de sécurité des données de l'entreprise. Il y a donc un 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 construction et du test d'API sur un extrait d'un ensemble de données, mais de l'utilisation du code sur un ensemble de données plus large en production. Elle peut également résulter de problèmes d'authentification (voir ci-dessus).

Atténuation

Tester des jeux de données qui limitent le nombre d'enregistrements, mais pas les types ou les champs contenus, afin de valider l'accès avec plus de précision. Utiliser des systèmes de prévention des pertes de données pour surveiller et alerter, bloquer ou expurger activement les données qui ne devraient pas être révélées de cette manière.

Dépendance à l'égard de l'API

Lorsque les processus internes dépendent des mêmes services API que les intégrations externes, les processus métiers de l'entreprise sont exposés aux interférences des utilisateurs d'API. Les attaques DoS axées sur les API peuvent paralyser les processus internes - et pas seulement les processus externes - et entraver gravement la capacité de l'entreprise à exercer ses activités.

Atténuation

Séparer les services API orientés vers l'intérieur de ceux orientés vers l'extérieur afin d'empêcher les attaques sur les API externes d'affecter directement les API internes.

Autres sources de risque pour l'API

D'autres sources de risque courantes pour les entreprises qui publient des API sont les suivantes :

• Contrôle inadéquat de la version des services sous-jacents aux API, ce qui entraîne des incohérences dans l'authentification, l'autorisation et l'analyse des entrées.
• Absence ou inadéquation de l'enregistrement des activités des APIs et de la surveillance des enregistrements.

Risques liés à la consommation d'API

Les risques liés aux APIs ne se limitent pas à la publication ; considérez les risques suivants liés à leur consommation.

Consommation non sécurisée de données

Lorsqu'une organisation utilise des API pour extraire des données de systèmes tiers, elle court le risque que ces données soient mauvaises, voire malveillantes. Cela peut conduire l'organisation à prendre de mauvaises décisions et des mesures incorrectes, ou à communiquer aux autorités de réglementation, aux clients ou aux partenaires des informations erronées plutôt que des faits.

Atténuation

La validation des entrées est essentielle pour sécuriser les API. Gardez une trace de l'origine des données afin que les problèmes puissent être correctement attribués et examinés.

Risque tiers non documenté

Les entreprises s'exposent à des problèmes lorsqu'elles prennent des risques tiers, c'est-à-dire des risques provenant des fournisseurs de leurs fournisseurs.

Tant d'API consomment d'autres API tierces - qui peuvent consommer d'autres API encore et ainsi de suite - qu'il peut être difficile de savoir combien d'entités différentes peuvent finalement être impliquées dans la fourniture de la réponse à une requête API. Il peut en résulter 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. Cherchez à conclure des accords contractuels avec ces autres fournisseurs d'API afin de définir et de limiter le risque lié aux tiers.

Risque non documenté pour les processus d'entreprise

Lorsque les processus d'entreprise dépendent de la consommation d'API mais que cette dépendance n'est pas documentée, il est très facile d'interrompre le processus.

Les modifications apportées aux processus opérationnels peuvent être effectuées sans tenir compte du fait qu'elles nécessitent des changements dans la manière dont les API sont utilisées - par exemple, ce qui entraîne un fonctionnement incorrect du processus. Ou encore, les modifications apportées au fonctionnement d'une API peuvent entraîner des changements subtils dans son comportement, qui posent problème mais ne sont pas immédiatement visibles.

Atténuation

Documenter minutieusement tous les processus d'entreprise. Utiliser des architectures sans confiance pour empêcher les systèmes internes d'accéder aux API internes ou externes sans autorisation explicite.

Les risques inhérents aux API ne sont pas propres à ces dernières. Pour gérer les principaux risques liés aux API et garantir la sécurité du réseau de l'entreprise, les systèmes informatiques et de cybersécurité doivent connaître les types de problèmes à l'origine des risques, ainsi que les outils et les stratégies conçus pour atténuer ces dangers.