Les 10 principaux risques de sécurité des API selon l’OWASP

Lorsqu’on cherche à renforcer la sécurité des API, il peut être difficile de savoir par où commencer. Votre équipe se demande peut-être ce qui distingue une vulnérabilité « critique » d’une vulnérabilité « non critique », et quels outils mettre en place pour atténuer les risques les plus graves auxquels sont exposées les applications backend (c’est-à-dire les serveurs) et les autres systèmes reposant sur des API.

Dans son ensemble, le secteur de la cybersécurité répond à ces questions en créant des cadres qui s’appuient sur des recherches pour déterminer les risques à traiter en priorité et la manière d’y répondre. Parmi les évolutions récentes figure l’OWASP API Top 10, un cadre dédié à la sécurisation des API.

Présentation de l’OWASP API Top 10

Depuis plus de dix ans, la fondation OWASP fournit des recommandations de sécurité aux organisations. Son initiative la plus connue est le projet OWASP Top 10, lancé en 2003 et mis à jour récemment pour 2021.

En 2019, la première liste OWASP dédiée à la sécurité des API a été publiée. L’OWASP a choisi de la créer en raison de l’importance des API et des risques croissants qu’elles font peser sur la posture de sécurité des applications mobiles, SaaS et web actuelles.

Pourquoi utiliser l’OWASP API Security Top 10 ?

Aujourd’hui, les éditeurs de logiciels ne peuvent pas innover sans API. Celles-ci constituent le socle d’innombrables applications, qu’elles aident à intégrer et à partager facilement des données et des fonctionnalités avec d’autres entités, comme des tiers et d’autres équipes de développement internes. L’essence même d’une API est donc de faciliter l’échange de données et l’interopérabilité. Malheureusement, cela permet aussi aux attaquants d’exposer facilement la logique applicative et les données sensibles transmises par une API. Et comme ces API sont souvent accessibles au public, le risque qu’elles soient utilisées par des acteurs malveillants est considérable.

Sécurité des applications web et sécurité des API

Pourquoi l’OWASP a-t-elle publié une liste distincte des 10 principales vulnérabilités des API ? Parce que les API et les applications web, bien qu’elles dépendent souvent les unes des autres, sont des technologies distinctes qui peuvent présenter des types de risques différents.

Sécurité des applications web

Les applications web traditionnelles comportent principalement des points d’entrée à deux endroits : côté client et côté serveur. Les principales menaces qui pèsent sur les applications web sont généralement liées à des faiblesses dans l’une de ces deux catégories.

Parmi les vulnérabilités des applications répertoriées dans l’OWASP Top 10, on trouve les problèmes de contrôle d’accès, qui permettent à des personnes non autorisées d’accéder au serveur, et les défaillances cryptographiques, qui surviennent lorsque les données du serveur ne sont pas correctement chiffrées.

Comme nous pouvons le constater, ces deux types de risques sont directement liés au serveur. En effet, les applications web ont un nombre limité de points d’entrée : les données sont traitées côté serveur, la page web est affichée dans le navigateur du client, l’utilisateur renvoie une requête, qui parvient de nouveau au serveur. Il s’agit d’un échange simple dans les deux sens. Même si les acteurs malveillants peuvent altérer n’importe quelle partie de ce processus, les points d’entrée restent limités.

Sécurité des API

Les API, en revanche, peuvent présenter une surface d’attaque très vaste, car elles exposent de nombreux points de terminaison auxquels des acteurs malveillants peuvent accéder pour consulter des données sensibles. Les composants d’une même application utilisent chacun des API pour envoyer des données aux serveurs et en recevoir. Une application peut comporter de nombreux points d’entrée destinés aux clients, que les attaquants peuvent tous exploiter.

Comme nous l’avons indiqué plus haut, les API ont par nature vocation à exposer des données. Lorsqu’elles fonctionnent comme prévu, elles rendent les applications beaucoup plus efficaces, car elles peuvent « communiquer » avec d’autres applications et bases de données. Malheureusement, cette même caractéristique rend les risques de sécurité des API particulièrement dommageables pour les entreprises qui les utilisent.

Les 10 principaux risques de sécurité des API selon l’OWASP, expliqués

La liste OWASP API Security classe les principales vulnérabilités susceptibles de compromettre la sécurité de votre serveur d’applications. Elle fournit à vos équipes des orientations précieuses pour choisir des solutions et des services afin de renforcer la sécurité de vos API et d’améliorer la posture de sécurité de bout en bout de toute votre organisation.

Voici la liste complète. Vous pouvez accéder directement à chaque section :

1. Autorisation défaillante au niveau des objets

2. Authentification utilisateur défaillante

3. Exposition excessive de données

4. Absence de limitation des ressources et du débit

5. Autorisation défaillante au niveau des fonctions

6. Affectation de masse

7. Erreur de configuration de sécurité

8. Injection

9. Gestion inadéquate des ressources

10. Journalisation et surveillance insuffisantes

N° 1 : autorisation défaillante au niveau des objets

Les API utilisent l’autorisation au niveau des objets pour s’assurer que seuls les utilisateurs autorisés peuvent accéder aux données fournies par l’API. Si ce mécanisme de contrôle d’accès est défaillant, les attaquants peuvent utiliser l’API pour divulguer, modifier ou détruire des données qui ne leur appartiennent pas ou auxquelles ils ne devraient pas avoir accès.

N° 2 : authentification utilisateur défaillante

Les points de terminaison et les flux d’authentification des utilisateurs sont considérés comme défaillants si l’API n’utilise pas des mécanismes de sécurité adéquats, tels que des clés de chiffrement robustes, la prévention des attaques par bourrage d’identifiants ou des mots de passe fortement hachés. Si un développeur ne renouvelle pas les clés ou ne configure pas l’authentification par jeton, les attaquants peuvent obtenir les identifiants d’une autre personne et les utiliser pour accéder aux API.

Par exemple, plusieurs versions du logiciel GitLab n’appliquent pas correctement les autorisations sur les pipelines planifiés. Cette vulnérabilité pourrait permettre à un utilisateur malveillant d’exécuter un pipeline dans le contexte d’un autre utilisateur.

N° 3 : exposition excessive de données

Cette vulnérabilité apparaît lorsqu’une API fournit plus d’informations qu’elle ne le devrait, ce dont les attaquants peuvent tirer parti. Ce type d’exposition de données est courant, car les développeurs implémentent souvent les API de manière générique, sans limiter les points de terminaison. Ils doivent au contraire choisir avec soin les points de terminaison à exposer et, par défaut, filtrer les autres.

Moodle, une plateforme d’apprentissage, en est un exemple. La fonctionnalité de téléchargement de tableaux de Moodle inclut les adresses e-mail des utilisateurs dans le tableau, même lorsqu’elles sont masquées. Une simple mise à niveau permet de corriger cette vulnérabilité.

N° 4 : absence de limitation des ressources et du débit

Des vulnérabilités apparaissent lorsque les équipes de développement n’imposent aucune limite à la taille ou au nombre de ressources qu’un client peut demander. Les attaquants peuvent lancer des attaques par force brute ou par déni de service lorsqu’ils disposent d’un nombre illimité de « tentatives » pour envoyer la bonne requête.

Par exemple, le middleware `express-brute` possède un package vulnérable au contournement de la limitation du débit. Un comptage incorrect du nombre de requêtes envoyées permet à un attaquant de contourner le mécanisme de limitation du débit.

N° 5 : autorisation défaillante au niveau des fonctions

Lorsqu’un système de contrôle d’accès est mal configuré, les attaquants peuvent accéder sans autorisation aux points de terminaison de l’API et exploiter leurs nouveaux privilèges.

`github.com/matrix-org/gomatrixserverlib`, une bibliothèque Go regroupant des fonctions courantes pour les serveurs Matrix, possède une version du package dans laquelle la fonction d’analyse des niveaux de puissance peut échouer. Les événements peuvent alors être autorisés ou rejetés à tort par les serveurs Dendrite. Cette vulnérabilité peut exposer les organisations à une attaque par déni de service (DoS).

N° 6 : affectation de masse

Cette vulnérabilité survient lorsqu’une API associe des données fournies par le client à des modèles de données. Un client malveillant peut alors modifier les propriétés d’un objet en altérant simplement les champs qui lui sont destinés.

laravel/framework, un framework d’applications web, en est un exemple. Les versions concernées de ce package sont vulnérables à l’affectation de masse lorsque la propriété `fillable` n’est pas utilisée dans les modèles.

N° 7 : erreur de configuration de sécurité

Cette catégorie regroupe les vulnérabilités dues à une mauvaise mise en place des configurations de sécurité. Voici quelques exemples d’erreurs de configuration susceptibles d’affecter une API :

• Absence de correctifs de sécurité

• Fonctionnalités inutiles activées

• Le système n’utilise ni Transport Layer Security (TLS) ni politique de partage des ressources entre origines (CORS)

• Les messages d’erreur exposent des informations sensibles

`typo3/cms`, un framework gratuit de gestion de contenu open source, possède plusieurs versions vulnérables à une erreur de configuration de sécurité pouvant entraîner la création d’un compte sans identifiants. Cette faiblesse peut être exploitée par un utilisateur du backend disposant des privilèges d’accès appropriés.

N° 8 : injection

Les acteurs malveillants lancent des attaques par injection en transmettant des données malveillantes au système via la couche API. Les API peuvent être touchées lorsqu’elles ne valident ni ne nettoient les données. Par exemple, `simple-git` est vulnérable à l’injection de commandes par injection d’arguments dans les versions 3.3.0 et antérieures. L’injection de certaines options git permettait d’exécuter des commandes arbitraires.

 N° 9 : gestion inadéquate des ressources

Les équipes doivent s’efforcer de comprendre la fonction et la composition de chaque API, puis de consigner ces informations de manière exhaustive. À défaut, elles risquent de ne pas mettre à jour, réparer ou retirer leurs API au moment opportun. Une API obsolète est bien plus vulnérable aux attaques qu’une API à jour.

N° 10 : journalisation et surveillance insuffisantes

Sans journalisation ni surveillance adéquates, un attaquant peut tenter à plusieurs reprises de pénétrer dans les systèmes sans que l’équipe de sécurité s’en aperçoive.

Deux étapes pour renforcer la sécurité de vos API

Pour traiter les risques liés à l’OWASP Top 10 pour les API, votre équipe peut suivre deux étapes afin de combler les éventuelles lacunes de sécurité : rechercher les vulnérabilités et sensibiliser l’équipe aux risques liés aux API.

Recherche des vulnérabilités des API

Les équipes de sécurité doivent rechercher régulièrement les vulnérabilités des API à l’aide de technologies qui analysent le code backend des API, détectent les risques et permettent d’y remédier. S’exercer sur un projet connu comme vulnérable constitue un moyen efficace de vérifier les méthodes d’analyse de votre équipe. Ces projets sont disponibles auprès de diverses ressources, notamment l’OWASP. 

Comment rechercher les vulnérabilités des API

Snyk propose diverses ressources pour aider votre équipe à effectuer des analyses de sécurité des API. Snyk Code permet d’analyser le code backend de vos API et de détecter les injections, les problèmes d’authentification utilisateur, l’exposition excessive de données et d’autres problèmes de sécurité. Snyk IaC vous aide à détecter les erreurs de configuration de sécurité (risque n° 7 de l’OWASP API) lorsque vous configurez votre infrastructure pour déployer vos conteneurs ou fonctions sans serveur dans le cloud.

Sensibilisez votre équipe aux vulnérabilités de l’OWASP API Top 10

Les équipes doivent également acquérir des connaissances pratiques sur l’OWASP Top 10. En comprenant réellement les causes de chaque type de vulnérabilité, elles seront moins susceptibles de contribuer à ces risques et plus enclines à aider à les corriger.

En plus de proposer des formations sur les vulnérabilités courantes, votre organisation doit également mettre en place des politiques de sécurité solides et donner à vos développeurs les moyens de les appliquer grâce à des formations pratiques. Snyk Learn propose des formations utiles sur différents sujets de sécurité, notamment les vulnérabilités des API. En maîtrisant les bonnes pratiques de sécurité, les développeurs peuvent améliorer votre posture de sécurité globale grâce au développement sécurisé, à une meilleure adhésion et à une correction plus rapide.

Comment Snyk contribue à la sécurité des API

Snyk fournit non seulement des ressources pour aider les organisations à sécuriser leurs API, mais propose aussi des solutions de sécurité des applications et du cloud. Nous mettons également à la disposition des équipes des ressources pédagogiques sur les vulnérabilités courantes dans différents langages et frameworks, comme Java.

Notre objectif est de proposer des ressources shift-left, adaptées aux développeurs, qui sécurisent l’ensemble de votre cycle de développement logiciel (SDLC) sans compromettre votre agilité. Contactez-nous dès aujourd’hui pour planifier votre démo.