Les principaux risques de sécurité des API

Quels sont les principaux risques de sécurité des API ?

Les principaux risques de sécurité des API sont les faiblesses que les attaquants exploitent le plus souvent pour lire les données d'autrui, prendre le contrôle de comptes ou mettre un service hors ligne. La liste de référence est l'OWASP API Security Top 10, publié pour la dernière fois pour 2023. Elle nomme dix catégories, surtout liées à des contrôles manquants côté serveur : qui peut voir quel objet, quel champ, quelle fonction, et combien il peut consommer. Chaque risque ci-dessous a une courte explication et le correctif habituel.

L'OWASP API Security Top 10 (2023)

API1:2023 Broken Object Level Authorization

L'API reçoit un identifiant d'objet du client (par exemple /orders/1043) et renvoie l'enregistrement sans vérifier que l'appelant a le droit de le voir. Correctif : vérifier l'appartenance à chaque accès à un objet, côté serveur, et utiliser des identifiants imprévisibles en couche supplémentaire, pas en remplacement.

API2:2023 Broken Authentication

La connexion ou la gestion des jetons et des clés est faible : pas de limite d'essais, jetons qui n'expirent jamais, secrets dans les URL ou jetons non signés acceptés. Correctif : jetons de courte durée, vérification stricte de la signature et de l'expiration, limites sur les tentatives d'identification.

API3:2023 Broken Object Property Level Authorization

L'appelant peut voir ou modifier un objet mais pas tous ses champs : les réponses en exposent trop (excessive data exposure) ou l'API laisse écrire des champs comme role ou price (mass assignment). Correctif : listes explicites de champs autorisés en sortie et en entrée.

API4:2023 Unrestricted Resource Consumption

Les requêtes consomment du CPU, de la mémoire, de la bande passante ou des appels tiers payants sans plafond : un seul client peut dégrader le service ou faire exploser la facture. Correctif : limites de débit, plafonds de taille de charge et de page, délais d'expiration et quotas par client. C'est aussi le risque que révèle un test de charge.

API5:2023 Broken Function Level Authorization

Des utilisateurs ordinaires peuvent appeler des fonctions d'administration ou privilégiées, par exemple en remplaçant GET par DELETE ou en devinant un chemin /admin. Correctif : refuser par défaut et vérifier le rôle de l'appelant pour chaque fonction, pas seulement dans l'interface.

API6:2023 Unrestricted Access to Sensitive Business Flows

Un parcours légitime, comme l'achat d'un stock limité, la publication de commentaires ou l'utilisation d'un coupon, peut être automatisé à une échelle qui nuit à l'activité. Correctif : détecter l'automatisation, ajouter de la friction sur les parcours sensibles et limiter par appareil, compte et règle métier. Voir abus d'API.

API7:2023 Server Side Request Forgery

L'API récupère une URL fournie par le client : un attaquant peut ainsi faire appeler par le serveur des services internes ou les endpoints de métadonnées du cloud. Correctif : liste blanche de destinations, blocage des plages d'adresses privées et jamais de renvoi brut des réponses récupérées.

API8:2023 Security Misconfiguration

Valeurs par défaut et dérive de configuration : messages d'erreur trop bavards, TLS absent, CORS permissif, méthodes HTTP inutiles, composants non corrigés. Correctif : une base durcie et reproductible, relue dans le code, et un contrôle que la production lui correspond.

API9:2023 Improper Inventory Management

D'anciennes versions, des hôtes de test et des endpoints non documentés restent joignables et non corrigés. Correctif : tenir un inventaire à jour des hôtes, versions et responsables, et retirer ce qui n'a pas de propriétaire. Voir API sprawl.

API10:2023 Unsafe Consumption of APIs

Votre service fait plus confiance aux données d'API tierces qu'à celles des utilisateurs : un partenaire compromis ou défaillant peut injecter de mauvaises données ou rediriger le trafic. Correctif : valider et borner ce que peuvent provoquer les réponses tierces, imposer TLS et délais d'expiration et les traiter comme une entrée non fiable.

Comment utiliser la liste

Commencez par API1, API2 et API5 : les failles d'autorisation et d'authentification causent les fuites les plus graves, et un scanner les détecte mal car chaque requête paraît valide. Testez-les avec deux comptes : connectez-vous en tant qu'utilisateur A et demandez des objets de l'utilisateur B, puis recommencez sans jeton. Rattachez ensuite le reste à votre stack. La discipline dans son ensemble est décrite dans sécurité des API, et les techniques des attaquants dans attaques d'API.

Erreurs courantes

• Vérifier l'autorisation uniquement dans l'interface. L'API est appelée directement : chaque contrôle doit être sur le serveur.
• Traiter la liste comme une case à cocher une fois pour toutes. De nouveaux endpoints et versions ramènent les mêmes risques.
• Prendre les identifiants pour des secrets. Un identifiant difficile à deviner n'est pas une autorisation.
• Laisser fuiter des identifiants. Les jetons dans les URL et les journaux finissent entre de mauvaises mains. Voir bearer token.
• Ignorer les limites. Sans limite de débit, plafond de taille de page ni délai d'expiration, API4 est ouvert.

Où la supervision et les tests aident

LoadFocus n'est pas un scanner de vulnérabilités et ne détecte ni les failles d'injection ni les erreurs d'autorisation. Il peut néanmoins appuyer certains de ces contrôles. La supervision d'API envoie des vérifications HTTP planifiées et contrôle le code de statut, les en-têtes et le corps de la réponse : vous pouvez être alerté si un endpoint censé répondre 401 ou 403 sans jeton se met à renvoyer 200, ou si une ancienne version retirée réapparaît. Les tests de charge montrent le comportement d'un endpoint sous de nombreuses requêtes simultanées, donc si les limites derrière API4 tiennent vraiment. Pour choisir des outils, lisez notre panorama des outils de supervision d'API (en anglais). Pour les tests d'intrusion et les scans de vulnérabilités, utilisez un outil de test de sécurité dédié.

Questions fréquentes

Quel est le risque de sécurité des API numéro un ?

Dans l'OWASP API Security Top 10 de 2023, la première entrée est Broken Object Level Authorization (BOLA). Elle survient quand une API renvoie un objet par son identifiant sans vérifier que l'appelant a le droit d'y accéder.

En quoi le Top 10 des API diffère-t-il de celui des applications web ?

La liste des applications web couvre des problèmes côté navigateur comme l'injection et le cross-site scripting. Celle des API se concentre sur la façon dont les API exposent directement des objets, des propriétés et des parcours métier : l'autorisation et les limites de ressources y sont donc bien mieux classées.

À quelle fréquence l'OWASP API Security Top 10 est-il mis à jour ?

L'édition actuelle date de 2023, la précédente de 2019. Consultez le site de l'OWASP pour la version la plus récente avant de fonder une revue dessus.

Un test de charge peut-il détecter des problèmes de sécurité d'API ?

Pas directement. Un test de charge montre le comportement d'une API sous fort trafic, ce qui aide à confirmer les limites de débit et plafonds de ressources. Il ne détecte pas les failles d'autorisation ou d'injection : il faut donc encore des tests de sécurité.