Dans de nombreuses équipes, la discussion sur la sécurité des API démarre et se termine trop vite. Quelqu’un demande si l’API est protégée, et la réponse devient presque instinctive: « oui, elle utilise HTTPS, JWT, OAuth, API Gateway et validation de jeton ».
Parfait. C’est nécessaire.
Mais cela est loin d’être suffisant.
Une API authentifiée peut encore être exposée de manière dangereuse. Un jeton valide peut encore être utilisé de façon abusive. Un consommateur légitime peut encore accéder à davantage de données que prévu. Un point de terminaison ancien peut rester actif sans que personne ne s’en rende compte. Et une intégration créée comme exception peut rester ouverte pendant des années, hors du radar de la gouvernance.
La sécurité des API, dans des environnements matures, ne consiste pas seulement à contrôler qui entre. Il s’agit de comprendre ce qui est exposé, qui consomme, avec quelles autorisations, dans quel cadre, selon quel schéma d’utilisation et avec quelle capacité à détecter les abus.
L’authentification est la porte d’entrée. La sécurité des API véritable commence lorsque l’organisation prend en main la gouvernance de l’exposition et du comportement.
L’essentiel compte, mais cela ne met pas fin à la discussion
Avant d’aller plus loin, il est utile de préciser: les bases sont indispensables.
Il n’y a pas de discussion mature sur la sécurité des API sans :
- HTTPS
- Authentification forte
- OAuth ou OIDC lorsque applicable
- Validation correcte des jetons
- Expiration et rotation
- Scopes bien définis
- API Gateway ou couche équivalente
- Journaux d’accès minimaux
- Contrôle de l’origine et transport sûr
Ces éléments réduisent des risques importants. Ils empêchent les accès anonymes non désirés, standardisent l’entrée, facilitent l’intégration à l’identité d’entreprise et créent une base minimale pour le contrôle.
L’erreur est de les traiter comme une ligne d’arrivée.
Dans des systèmes simples, cette couche peut résoudre une bonne partie du problème. Dans des écosystèmes avec de nombreux consommateurs, partenaires, équipes internes, versions, gateways, BFFs, intégrations héritées et API publiques, le risque apparaît à un autre niveau.
L’attaquant n’a pas toujours besoin de briser la porte. Parfois, il entre par la bonne porte et utilise l’autorisation d’une manière à laquelle personne n’avait pensé.
Le problème ne réside pas seulement dans qui accède, mais dans ce qu’il peut faire
L’authentification répond à une question importante: qui êtes-vous ?
Mais la sécurité des API doit répondre à d’autres questions également :
- Pouvez-vous accéder à cette ressource ?
- Pouvez-vous exécuter cette action ?
- Pouvez-vous faire cela dans ce contexte ?
- Pouvez-vous effectuer cela à cette fréquence ?
- Pouvez-vous interroger cet ensemble de données ?
- Pouvez-vous combiner ces appels pour extraire des informations sensibles ?
- Ce comportement est-il normal pour ce consommateur ?
Quand l’architecture ne répond pas à ces questions, l’API peut être authentifiée et néanmoins dangereuse.
Voyons un exemple simple :
GET /users/987654/orders
Authorization: Bearer <valid-token>Si le jeton est valide, la requête passe l’authentification. Mais cela ne signifie pas que le consommateur devrait accéder aux commandes de l’utilisateur 987654.
Ici, le problème n’est pas l’authentification. C’est l’autorisation sur la ressource. Et ce type de faille demeure l’une des sources de risque les plus courantes dans les API.
Dans des environnements matures, le contrôle doit être plus granulaire. Il ne suffit pas de valider le jeton. Il faut valider la relation entre identité, portée, ressource, action et contexte.
API exposées sans gouvernance deviennent une surface invisible
L’un des plus grands risques dans les organisations avec de nombreuses équipes est simple et redoutable: personne ne sait exactement quelles API sont exposées.
Cela se produit progressivement.
Un point d’accès temporaire est créé pour soutenir une intégration d’urgence. Une version ancienne demeure active parce qu’un partenaire l’utilise encore. Un service interne est exposé par exception. Un BFF publie une route qui aurait dû rester interne. Une documentation devient obsolète. Une API change de propriétaire après une réorganisation des équipes.
Soudainement, l’entreprise se retrouve avec une surface qu’aucun œil ne voit dans sa globalité.
Ce sont ce que l’on appelle les shadow APIs ou APIs hors du radar de la gouvernance. Et elles sont dangereuses précisément parce qu’elles n’apparaissent pas lors des revues officielles.
Le problème est simple: on ne protège pas ce que l’on ne voit pas.
Si l’organisation ne dispose pas d’un inventaire réel des API, de propriétaires clairement identifiés, d’environnements cartographiés, de versions sous contrôle et de consommateurs connus, la sécurité dépend alors de la mémoire institutionnelle. Or, la mémoire institutionnelle n’est pas un contrôle de sécurité.
L’abus d’API ne ressemble pas toujours à une intrusion
Un autre point que les équipes seniors doivent prendre très au sérieux: de nombreuses expositions d’API ne ressemblent pas à une attaque spectaculaire. Elles ressemblent à une utilisation intensive, créative ou abusive de fonctionnalités légitimes.
Quelques exemples :
- Énumération d’identifiants
- Scraping de données
- Credential stuffing sur le point de connexion
- Utilisation excessive de la recherche
- Appels automatisés contre des endpoints publics
- Exploitation des filtres pour déduire des informations
- Abus des règles métier
- Consommation excessive par un partenaire légitime
- Extraction progressive de données par pagination
Tout cela peut se produire avec une authentification valide.
Imaginez un endpoint de recherche de commandes. Un partenaire légitime a accès pour consulter les données opérationnelles. Mais sans rate limit, sans limites de portée et sans détection de schémas anormaux, ce point d’accès peut devenir un canal d’extraction massive de données.
Le système peut sembler « fonctionner correctement » d’un point de vue technique. Mais d’un point de vue sécurité, il échoue.
C’est le genre de risque que n’importe quelle approche basique ne capture pas bien.
La limitation de débit n’est pas seulement une protection contre un trafic élevé
La limitation de débit est généralement vue comme une défense contre un excès de requêtes. C’est vrai, mais c’est peu.
Dans des API matures, la limitation de débit est aussi un mécanisme de contrôle du comportement.
Il ne suffit pas de limiter globalement. Il faut envisager des limites par :
- Consommateur
- Endpoint
- Portée
- Type d’opération
- Sensibilité de la ressource
- Modèle d’utilisation historique
- Environnement
Un exemple conceptuel :
consumer_id: partner-x
limit: 1000 req/min
burst: 1500
scope: read:ordersCe type de contrôle ne sert pas seulement à maintenir l’infrastructure en vie. Il sert à réduire les abus, à limiter l’extraction non autorisée et à établir des frontières opérationnelles plus nettes.
Et ici intervient un point important: les limites ne devraient pas être les mêmes pour tout.
Une API publique de catalogue peut tolérer un profil. Une API de données financières devrait avoir un autre. Une opération d’écriture critique devrait être soumise à bien plus de contrôle qu’une simple requête et mise en cache.
La sécurité mature prend en compte le comportement et la sensibilité, et non seulement le volume.
Autorisation contextuelle: l’étape que beaucoup d’API sautent
Beaucoup d’implémentations restent prisonnières d’une autorisation trop générale: l’utilisateur a un rôle, le jeton a une portée, l’appel passe.
Pourtant, dans les API plus sensibles, la question doit être contextuelle.
Par exemple :
- Cet utilisateur appartient-il à cette organisation ?
- Ce partenaire peut-il consulter cette ressource spécifique ?
- Cette application peut-elle exécuter cette opération dans cet environnement ?
- Cette action a-t-elle du sens pour ce type de compte ?
- Le volume de données demandé correspond-il au profil de ce consommateur ?
- Cet appel provient-il d’un contexte attendu ?
Ce type d’autorisation est plus lourd à mettre en place, mais bien plus proche de la réalité.
La sécurité cesse d’être uniquement « peut ou ne peut pas accéder à l’API » et devient « peut réaliser cette action sur cette ressource, dans ce contexte, avec ce niveau de portée ».
Ce raffinement est particulièrement important pour les API B2B, multi-locataires, financières, administratives ou contenant des données personnelles sensibles.
Journaux d’accès: les logs ne constituent pas nécessairement une audit utile
Autre erreur fréquente: croire que disposer de journaux signifie posséder une capacité d’enquête.
De nombreuses API enregistrent trop d’informations pour l’observabilité générale et pas assez pour la sécurité. Le journal existe, mais il ne répond pas aux questions pertinentes.
En cas d’incident, l’équipe doit savoir :
- Qui a appelé ?
- Quel consommateur ?
- Quel est le périmètre ?
- Quelle ressource ?
- Quelle action ?
- Quelle origine ?
- Quelle décision d’autorisation a été prise ?
- Quelle corrélation avec d’autres appels ?
- Y avait-il un schéma anormal avant l’événement ?
Sans ce type d’information, l’enquête deviendra une reconstitution manuelle.
Ce cadre ne remplace pas une analyse formelle de la sécurité, mais il améliore déjà considérablement la qualité du dialogue technique.
La séniorité apparaît lorsque la sécurité devient une opération continue
Les professionnels seniors savent que la sécurité n’est pas une phase. Ce n’est pas quelque chose qui se produit uniquement lors de la revue avant le déploiement. Et ce n’est pas seulement un ensemble de bibliothèques, jetons et configurations de passerelle.
La sécurité des API est une opération continue.
Elle exige :
- Inventaire
- Propriété
- Limites
- Télémétrie
- Révision des autorisations
- Mise au rebour des versions anciennes
- Détection d’abus
- Gouvernance de la consommation
C’est là où bon nombre d’architectures échouent encore. L’équipe met en place des contrôles d’entrée, mais elle n’alimente pas une vision vivante de l’exposition.
Et une exposition qui n’est pas gouvernée devient un risque cumulé.
Conclusion
L’authentification est indispensable. OAuth, JWT, les clés API, les passerelles et HTTPS restent des éléments importants de la sécurité des API. Mais cela ne suffit pas.
Dans des environnements matures, le véritable défi réside dans le contrôle de l’exposition, des abus, du contexte, des autorisations et de la gouvernance. Il s’agit de savoir quelles API existent, qui les consomme, ce que chaque consommateur peut faire et comment détecter des schémas anormaux avant qu’ils ne deviennent des incidents.
Une API sécurisée n’est pas celle qui se contente d’authentifier correctement. C’est celle qui connaît sa surface, comprend ses consommateurs et limite l’abus de manière continue.
Réalisez un inventaire réel des API exposées, des consommateurs critiques et des points qui ne bénéficient pas encore d’une gouvernance suffisante.
