Série OWASP Top 10 API : Manque de ressources et limitation du débit

En raison du manque de ressources et de limitation de débit, la vulnérabilité des API correspond exactement à ce que son nom indique. Chaque API dispose de ressources et d'une puissance de calcul limitées en fonction de son environnement. La plupart sont également tenues de traiter les requêtes des utilisateurs ou d'autres programmes sollicitant leurs fonctions. Cette vulnérabilité survient lorsqu'un trop grand nombre de requêtes est reçu simultanément et que l'API ne dispose pas de ressources informatiques suffisantes pour les traiter. L'API peut alors devenir indisponible ou ne plus répondre aux nouvelles requêtes.

Les API deviennent vulnérables à ce problème si leurs limites de débit ou de ressources ne sont pas correctement configurées, ou si elles ne sont pas définies dans le code. Une API peut être surchargée si, par exemple, une entreprise connaît une période d'activité intense. Mais il s'agit également d'une faille de sécurité, car des acteurs malveillants peuvent délibérément saturer des API non protégées de requêtes afin de mener des attaques par déni de service (DDoS).

Au fait, comment se passent vos défis de gamification sur les API jusqu'à présent ? Si vous souhaitez tester vos compétences en matière de gestion d'une vulnérabilité liée à la limitation de débit dès maintenant, entrez dans l'arène :

Approfondissons un peu le sujet.

Quels sont quelques exemples de vulnérabilités liées au manque de ressources et à la limitation de débit des API ?

Il existe deux façons pour cette vulnérabilité de s'immiscer dans une API. La première survient lorsqu'un développeur omet simplement de définir les taux de limitation (throttling) pour une API. Il peut exister un paramètre par défaut dans l'infrastructure, mais s'y fier n'est pas une bonne pratique. Au contraire, les taux de chaque API doivent être définis individuellement. C'est d'autant plus crucial que les API peuvent avoir des fonctions très variées ainsi que des ressources disponibles différentes.

Par exemple, une API interne conçue pour servir quelques utilisateurs seulement peut fonctionner parfaitement avec un taux de limitation très bas. En revanche, une API publique intégrée à un site e-commerce en direct nécessiterait probablement un taux exceptionnellement élevé pour compenser une éventuelle montée en charge simultanée d'utilisateurs. Dans les deux cas, les taux de limitation doivent être définis en fonction des besoins attendus, du nombre d'utilisateurs potentiels et de la puissance de calcul disponible.

Il peut être tentant, surtout pour des API très sollicitées, de définir les taux en illimité pour tenter de maximiser les performances. Cela pourrait être réalisé avec un simple morceau de code (à titre d'exemple, nous utiliserons le framework Python Django REST) :

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

Dans cet exemple, les utilisateurs anonymes comme ceux identifiés par le système peuvent contacter l'API un nombre illimité de fois, sans aucune restriction sur le volume de requêtes dans le temps. C'est une mauvaise idée, car peu importe les ressources informatiques dont dispose une API, les attaquants peuvent déployer des botnets pour finir par la ralentir considérablement, voire la mettre totalement hors ligne. Lorsque cela se produit, les utilisateurs légitimes se voient refuser l'accès et l'attaque est réussie.

Éliminer les problèmes de manque de ressources et de limitation de débit

Chaque API déployée par une organisation doit avoir ses taux de limitation définis dans son code. Cela peut inclure des paramètres tels que les délais d'expiration (timeouts), la mémoire maximale autorisée, le nombre d'enregistrements par page pouvant être renvoyés à un utilisateur, ou le nombre de processus autorisés dans un laps de temps défini.

En reprenant l'exemple précédent, au lieu de laisser les taux de limitation totalement ouverts, ils pourraient être strictement définis avec des seuils différents pour les utilisateurs anonymes et les utilisateurs connus.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

Dans ce nouvel exemple, l'API limiterait les utilisateurs anonymes à 200 requêtes par heure. Les utilisateurs connus, déjà validés par le système, bénéficient d'une plus grande marge de manœuvre avec 5 000 requêtes par heure. Mais même eux sont limités afin d'éviter une surcharge accidentelle lors des pics d'activité ou pour compenser le cas où un compte utilisateur serait compromis et utilisé pour une attaque par déni de service.

Enfin, une bonne pratique consiste à afficher une notification aux utilisateurs lorsqu'ils ont atteint les limites de débit, accompagnée d'une explication sur le moment où ces limites seront réinitialisées. Ainsi, les utilisateurs légitimes comprendront pourquoi l'application rejette leurs requêtes. Cela peut également s'avérer utile si des utilisateurs légitimes effectuant des tâches approuvées se voient refuser l'accès, car cela peut signaler au personnel opérationnel que les limites de débit doivent être augmentées.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre d'autres failles de sécurité. Vous pouvez également demander une démonstration de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.