SOC managé - surveillance continue  ·  veille cyber : CERT-FR / CISA / NVD  ·  réponse à incident en priorité
Toutes les actualités

Cyberdéfense · Guide

Sécurité des API : le nouveau champ de bataille.

Un grand hôtel a une entrée principale magnifique : hall de marbre, portier, réceptionniste qui vérifie chaque arrivant. C'est là que tout le monde regarde. Mais derrière le bâtiment court un réseau de couloirs de service, de monte-charges, de portes de livraison par où transitent le linge, les repas, les fournisseurs. Ces accès existent parce que l'hôtel ne pourrait pas fonctionner sans eux - et c'est précisément par là que passe qui veut entrer sans se faire remarquer. Les attaquants ont cessé de faire la queue devant le hall de marbre. Ils cherchent la porte de service qu'on a oublié de fermer.

Sur le web, ce hall de marbre, c'est l'interface que vous voyez à l'écran. Les couloirs de service, ce sont les API : ces canaux par lesquels applications, mobiles et partenaires échangent des données en coulisses. Elles sont devenues le socle du numérique moderne - et, du même coup, la première porte d'entrée des attaquants. Les fuites françaises récentes le confirment : France Titres (11,7 millions de comptes) comme la plateforme Betrail (2,8 millions de profils) ont été compromises non par la grande porte, mais par leurs API.

En résumé

  • Les attaquants ont cessé de faire la queue devant le hall de marbre : ils cherchent la porte de service. Sur le web, les couloirs de service, ce sont les API.
  • Deux fuites françaises récentes le confirment : France Titres (11,7 millions de comptes) et Betrail (2,8 millions de profils) ont été compromises par leurs API, pas par leur interface.
  • Trois raisons à ce déplacement du risque : les API exposent directement données et fonctions, elles se multiplient avec les microservices et les intégrations, et elles sont bien moins surveillées que les interfaces web.
  • Les failles récurrentes du top 10 API de l'OWASP : défaut d'autorisation au niveau objet (IDOR), authentification défaillante, exposition excessive de données, absence de limitation de débit, API fantômes.
  • La première faille est souvent une API oubliée - une version de test laissée accessible, un point d'entrée hérité d'un ancien projet. On ne protège que ce que l'on a inventorié.
  • Les parades : inventorier y compris les API des prestataires, contrôler l'autorisation objet par objet côté serveur, limiter le débit, minimiser les données renvoyées, journaliser, tester régulièrement.
hall principal, portier vérifie chacun couloir de service, à l'arrière chariots non contrôlés = les API
Le hall qu'on garde, le couloir de service qu'on oublie

Pourquoi les API sont devenues la cible privilégiée

Trois raisons expliquent ce déplacement du risque, et toutes tiennent dans la métaphore des couloirs de service :

  • Elles exposent directement données et fonctions, sans la couche visuelle d'une interface web qui, souvent, masquait la complexité.
  • Elles se multiplient : microservices, applications mobiles, intégrations partenaires… chaque API est un nouveau point d'entrée à sécuriser.
  • Elles sont moins surveillées que les interfaces classiques, et parfois oubliées (API « fantômes » laissées en ligne après un projet).

Les failles les plus fréquentes

L'OWASP maintient un top 10 spécifique aux API. Les récurrentes :

  • Défaut d'autorisation au niveau objet (IDOR) : accéder aux données d'un autre en changeant un identifiant. Nous y consacrons un article dédié.
  • Authentification défaillante : jetons mal protégés, absence de limitation des tentatives.
  • Exposition excessive de données : l'API renvoie plus d'informations que nécessaire, à charge du client de filtrer.
  • Absence de limitation de débit : rien n'empêche un attaquant d'aspirer des millions d'enregistrements.
  • API fantômes ou obsolètes : exposées sans que personne ne les surveille.
Connaissez-vous toutes vos API ?

La première faille est souvent une API oubliée : une version de test laissée accessible, un endpoint hérité d'un ancien projet. On ne protège que ce que l'on a inventorié. Cartographier ses API est le point de départ.

Sécuriser ses API : les bonnes pratiques

  • Inventorier toutes les API exposées, y compris les anciennes et celles des prestataires.
  • Contrôler l'autorisation objet par objet, côté serveur, systématiquement.
  • Limiter le débit et détecter les usages anormaux (énumération massive).
  • Minimiser les données renvoyées : ne transmettre que le strict nécessaire.
  • Journaliser et surveiller les appels, via une passerelle d'API et un SOC.
  • Tester régulièrement par des pentests d'API, avant et après mise en production.

En conclusion

Les API concentrent aujourd'hui la valeur… et le risque. Reprenons l'image de l'hôtel : on ne sécurise pas un bâtiment en polissant la porte d'entrée pendant que la porte de service bat au vent. Il faut d'abord savoir combien de portes existent - y compris celles qu'un projet oublié a laissées entrebâillées - puis appliquer avec rigueur autorisation, limitation et surveillance sur chacune. C'est un chantier transverse, à la croisée du développement, de l'exploitation et de la sécurité : exactement le type de sujet où un regard offensif, celui de quelqu'un qui pense en attaquant, fait toute la différence.

Évaluer la sécurité de vos API

Kenawek cartographie vos API, teste leur robustesse et vous aide à corriger les failles avant qu'elles ne soient exploitées. Parlons-en.

Sources

À lire aussi

Dans la même veine.