Sécurité des API : le point aveugle derrière chaque intégration

7 Min. Temps de lecture

Le frontend est sécurisé, la connexion est établie, le pare-feu est en place. Et puis une application mobile appelle une interface qui fournit toutes les commandes de chaque client dès que l’on incrémente le numéro dans la requête. Pas d’outil d’exploitation, pas de jour zéro, juste une vérification manquante. C’est précisément là, dans les API derrière les applications visibles, que la surface d’attaque s’est déplacée ces dernières années. Et elle est souvent moins bien protégée que ce qui se trouve à l’avant.

Les points clés en bref

La surface d’attaque a changé de place. Au lieu d’une seule page web, il y a maintenant des dizaines d’interfaces derrière les applications, les intégrations et les connexions partenaires, chacune avec son propre accès aux données.
BOLA est en tête de la liste OWASP. L’autorisation manquante au niveau de l’objet, l’incrémentation de l’ID étrangère suffit. Cela fait partie des erreurs API les plus courantes et se trouve rarement dans le code écrit intentionnellement.
On ne protège que ce que l’on connaît. Les API fantômes et zombies des anciennes versions sont le problème silencieux. Un inventaire API est l’étape 1, pas l’étape 5.
Les contre-mesures sont peu spectaculaires. Autorisation par objet, limitation de taux, validation de schéma à la passerelle. Cela fonctionne via la configuration et la discipline, pas via un appareil coûteux.

Pourquoi la surface d’attaque s’est déplacée derrière l’application

Il y a dix ans, la page web était la porte d’entrée. Aujourd’hui, la page web n’est plus que la façade, derrière laquelle travaillent les interfaces. L’application mobile parle avec une API, le portail partenaire tire des données via une API, l’ERP synchronise via une API, et l’assistant IA que quelqu’un vient d’installer appelle également une API. Chacune de ces connexions est une porte par laquelle les données entrent et sortent.

Vue rapprochée de code programmé mis en évidence sur un écran. — Les API sont souvent créées rapidement dans le code pour servir une application. La vérification de sécurité est alors volontiers reportée à plus tard. Photo : Godfrey Atima / Pexels

Le problème est que ces portes sont moins visibles que la page d’entrée. Un test de pénétration tapote sur l’application web, un point de terminaison API utilisé uniquement par une application passe facilement à travers les mailles du filet. C’est précisément ici que je ne me fie pas à mon sentiment d’avoir tout sous contrôle. J’ai trouvé plus souvent que je ne le souhaiterais une API dont l’équipe jurait qu’elle n’existait plus.

BOLA et la liste OWASP : où ça se casse concrètement

Qu’est‑ce que la sécurité des API ? La sécurité des API regroupe les mesures qui protègent une interface de programmation contre les abus : authentification correcte, autorisation au niveau des objets et des fonctions, limitation de la charge et validation des données transmises. Elle se différencie de la sécurité web classique, car avec une API chaque appel touche directement la logique métier, sans couche de protection en amont.

L’OWASP API Security Top 10 constitue la carte la plus utile des vulnérabilités qui apparaissent réellement en pratique. En tête se trouve BOLA, Broken Object Level Authorization. Le serveur vérifie si quelqu’un est connecté, mais pas si l’objet demandé lui appartient. Un appel à /api/orders/1043 renvoie votre propre commande, celui à /api/orders/1044 renvoie celle d’un tiers. Aucun outil n’est nécessaire, un simple compteur suffit.

Juste à côté se trouvent l’authentification défaillante, où les jetons vivent trop longtemps ou sont trop laxement vérifiés, et la consommation illimitée de ressources, où un seul client avec des requêtes incessantes met l’interface à genoux. Aucune de ces failles n’est exotique. Elles résultent du fait qu’une API a été construite rapidement pour servir une application, et les questions de sécurité ont été reportées à plus tard. Ce « plus tard » se réalise rarement en pratique.

Vue périmétrique classique	Réalité API
Protège l’application web visible	Des dizaines de points d’accès, dont beaucoup ne sont documentés nulle part
Attaque via les champs de saisie et les sessions	Attaque via des IDs incrémentées, des faiblesses de jetons et la charge
Un WAF couvre beaucoup	L’autorisation doit être gérée par objet dans l’application

Shadow‑APIs : on ne protège que ce que l’on connaît

Le plus gros problème n’est généralement pas l’interface dont tout le monde parle, mais celle dont personne ne se souvient. Les Shadow‑APIs apparaissent lorsqu’une équipe crée rapidement un point d’accès et ne l’intègre jamais à la documentation officielle. Les Zombie‑APIs sont d’anciennes versions qui restent actives après un déploiement, parce qu’elles ne nuisent à personne. Les deux sont non corrigées, non vérifiées et souvent dépourvues de règles d’accès à jour.

C’est pourquoi la sécurité des API ne commence pas par un outil, mais par une liste. Qui ne connaît pas ses points d’accès ne peut pas les sécuriser, les surveiller ni les désactiver. Cela paraît évident, mais c’est l’étape que la plupart sautent, car elle ressemble à du travail de fond. Sans ce travail de fond, le reste n’est que de la cosmétique.

Cinq étapes qui portent la majeure partie du fardeau

La bonne nouvelle pour les entreprises de taille moyenne : la sécurité des API ne nécessite rarement un nouvel appareil coûteux. Elle exige de faire quelques choses de manière cohérente. Ces cinq étapes portent la plus grande partie du fardeau.

Tenir un inventaire. Enregistrer chaque point de terminaison, y compris les anciens et les non officiels. Un passerelle ou un simple scan permet de voir ce qui est réellement accessible.
Vérifier l’autorisation par objet. À chaque appel, non seulement vérifier si quelqu’un est connecté, mais également si l’objet demandé lui appartient. C’est la réponse directe à BOLA.
Regrouper l’authentification à la passerelle. Contrôler les jetons, les dates d’expiration et les étendues de manière centralisée, au lieu de les construire dans chaque application de manière nouvelle et sujette aux erreurs.
Définir une limitation de débit. Une limite supérieure par client rend difficile l’essai rapide d’IDs et intercepte la surcharge causée par un seul appelant. La véritable solution à BOLA est fournie par l’autorisation d’objet de l’étape deux.
Valider les entrées selon le schéma. Ce qui ne correspond pas à la structure attendue est rejeté avant d’atteindre la logique métier.

Rien de tout cela n’est nouveau, et c’est précisément le point. Les lacunes dans les API ne se créent pas parce que les connaissances manquent, mais parce que l’interface a été construite sous pression et que la sécurisation a été retardée. Configurer cela une fois de manière propre comme standard est moins cher que le premier incident où quelqu’un a extrait les commandes de l’ensemble de la clientèle.

La première étape sans équipe de sécurité

Si vous n’avez pas d’équipe de sécurité, ne commencez pas avec l’outil le plus coûteux, mais avec la question la plus gênante : Quelles interfaces avons-nous, et qui peut accéder à quelles données via celles-ci ? La réponse à cela révèle généralement plus que n’importe quel scanner acheté. Une passerelle API que de nombreux fournisseurs de cloud fournissent de toute façon regroupe l’authentification, la limitation de débit et la journalisation en un seul endroit et transforme des portes dispersées en une entrée contrôlée.

Le reste est une question d’attitude. Une interface n’est terminée que lorsque quelqu’un a décidé qui peut l’appeler et ce qui se passe si quelqu’un le fait trop souvent. Tant que cette décision manque, l’API n’est pas un produit, mais une fenêtre ouverte que personne n’a encore trouvée.

Foire aux questions

Qu’est-ce qui distingue la sécurité des API de la sécurité Web classique ?

La sécurité Web classique protège une surface derrière laquelle se trouve la logique. Une API n’a pas de surface, chaque appel frappe directement la logique. C’est pourquoi un WAF ne suffit pas, le contrôle réel, en particulier l’autorisation par objet, doit se trouver dans l’application elle-même.

Qu’est-ce que BOLA et pourquoi est-il si répandu ?

BOLA signifie Broken Object Level Authorization. Le serveur vérifie si un utilisateur est connecté, mais pas si l’objet demandé lui appartient. Qui augmente un ID dans la requête voit des données étrangères. Il est répandu parce que la vérification est facilement oubliée lorsque une API est construite rapidement pour une application.

Ai-je besoin d’un outil de sécurité API coûteux ?

Pas au début. Un inventaire API, une autorisation par objet, une passerelle pour l’authentification et la limitation de débit ainsi que la validation de schéma couvrent la plus grande partie. Des outils spécialisés aident à la mise à l’échelle et à la détection des Shadow-API, mais ne remplacent pas les bases.

Quelles sont les Shadow- et Zombie-API ?

Les Shadow-API sont des points de terminaison qui ont été construits mais jamais documentés. Les Zombie-API sont de vieilles versions qui continuent à fonctionner après une version. Les deux se soustraient à la surveillance et portent souvent des règles d’accès obsolètes. Ils sont une raison principale pour laquelle un inventaire complet est la première étape.

Où un moyen entreprise sans équipe de sécurité devrait-il commencer ?

À l’inventaire : Quelles interfaces existent, et qui peut accéder à quelles données via celles-ci ? Ensuite, utiliser une passerelle API que de nombreux fournisseurs de cloud fournissent pour regrouper l’authentification, la limitation de débit et la journalisation de manière centralisée. C’est moins cher et plus efficace qu’un scanner acheté sans bases.