Sécuriser ses API : bonnes pratiques, d'OAuth 2.1 aux agents IA

SECTION 1

Les API, première surface d'attaque des systèmes distribués

Les API sont au cœur des architectures modernes, microservices, applications mobiles, écosystèmes de partenaires, ce qui en fait la cible privilégiée des attaquants. Les chiffres récents sont sans appel : 87 % des organisations déclarent avoir subi un incident de sécurité lié à leurs API en 2025 selon le rapport State of the Internet d'Akamai, et le nombre moyen d'attaques quotidiennes par organisation a plus que doublé en un an.

Le référentiel de menaces reste l'OWASP API Security Top 10, dont l'édition 2023 fait toujours autorité : autorisation défaillante au niveau des objets (BOLA), authentification cassée et mauvaises configurations concentrent l'essentiel des exploitations constatées. Autrement dit, les attaquants ne cassent pas la cryptographie, ils exploitent des logiques d'autorisation incomplètes et des API oubliées.

La pression monte encore avec l'IA : les vulnérabilités d'API liées aux intégrations d'intelligence artificielle ont été multipliées par près de cinq en un an selon le rapport API ThreatStats 2026, portées par la prolifération d'endpoints qui exposent des modèles et des outils agentiques. Chaque nouvelle interface d'IA est une API de plus à inventorier, à authentifier et à surveiller, souvent déployée plus vite que les processus de sécurité ne suivent.

Sécuriser ses API n'est donc plus un chantier périphérique : c'est un pilier de la posture de sécurité globale. Cinq fronts structurent une défense solide en 2026 : l'autorisation, la résistance des tokens au vol, la maîtrise du débit, la gouvernance du cycle de vie et, désormais, les consommateurs pilotés par l'IA.

SECTION 2

OAuth 2.1 et PKCE : l'autorisation à l'état de l'art

OAuth 2.1 est le standard de fait de l'autorisation : cette révision, en phase finale à l'IETF, consolide en un seul texte quinze ans de bonnes pratiques accumulées depuis OAuth 2.0, en intégrant notamment la RFC 9700 (Security Best Current Practice, publiée en janvier 2025). Les grands serveurs d'autorisation l'implémentent déjà : il n'y a aucune raison d'attendre la publication formelle du RFC pour s'y conformer.

### Les flux à utiliser : et ceux à proscrire

Le PKCE (Proof Key for Code Exchange) devient obligatoire pour tous les types de clients, y compris confidentiels. Trois flux couvrent les besoins légitimes : le code d'autorisation avec PKCE pour les applications avec navigateur, le device flow pour les clients sans navigateur, et le client credentials pour les échanges de serveur à serveur. Le flux implicite et le flux par mot de passe du propriétaire de la ressource sont formellement retirés : leur présence dans une API en 2026 est un signal d'alerte en soi.

### Redirections et protection anti-CSRF

Quelques règles complètent ce socle : des URI de redirection en HTTPS, absolues et comparées par correspondance exacte avec celles enregistrées ; le paramètre « state » en complément du PKCE contre les requêtes forgées inter-sites ; et un serveur d'autorisation unique pour centraliser la gestion des clés de signature plutôt que de disperser la confiance.

L'autorisation ne s'arrête pas à l'obtention du token : la majorité des exploitations constatées relèvent du contrôle d'accès au niveau des objets. Chaque handler doit vérifier que l'identité appelante a le droit d'accéder à la ressource précise demandée, jamais déduire ce droit du seul fait que la requête est authentifiée. Les scopes OAuth délimitent des familles d'actions ; la décision fine, elle, se joue côté application, idéalement centralisée dans un moteur de politiques testable plutôt que dispersée dans chaque endpoint.

SECTION 3

Des tokens résistants au vol : DPoP, mTLS et JWT bien employés

Le maillon faible historique de OAuth est le token porteur (bearer) : quiconque le détient peut l'utiliser. La réponse moderne est le token lié à son détenteur : avec DPoP (RFC 9449), le client prouve à chaque requête qu'il possède la clé privée associée au token ; avec le mTLS (RFC 8705), le token est lié au certificat client de la connexion. Dans les deux cas, un token exfiltré devient inutilisable par l'attaquant, un changement de paradigme pour les API sensibles.

### JWT : les règles qui ne changent pas

Les fondamentaux restent valides : des tokens opaques pour les échanges avec des tiers, les JSON Web Tokens réservés aux usages internes ; une expiration courte systématique, avec rotation des refresh tokens pour détecter leur réutilisation ; une liste blanche stricte des algorithmes de signature acceptés ; et jamais de donnée sensible dans la charge utile d'un JWT, lisible en clair par quiconque l'intercepte. La révocation doit enfin être outillée : un token compromis doit pouvoir être invalidé en minutes, pas en heures.

La gestion des secrets complète ce pilier : clés de signature stockées dans un gestionnaire dédié ou un HSM, rotation automatique et planifiée, interdiction absolue des secrets en dur dans le code ou les configurations des clients. Les incidents récents le rappellent : la fuite d'une clé d'API dans un dépôt public reste l'un des chemins d'attaque les plus courants, et les plus évitables. Le transport, enfin, reste la base : TLS 1.3 partout, y compris entre services internes, le trafic est-ouest étant devenu une cible aussi importante que le trafic exposé.

SECTION 4

Rate limiting et détection des abus de logique métier

La limitation du débit borne le nombre d'appels à l'API sur une période donnée. Elle prévient les attaques par déni de service, freine le credential stuffing et le scraping massif, et protège la fiabilité du service en empêchant qu'un client, malveillant ou non, ne sature les ressources partagées.

### Choisir son algorithme de limitation

Plusieurs algorithmes coexistent : le leaky bucket lisse le trafic en file premier entré, premier sorti ; la fenêtre fixe est simple mais vulnérable aux rafales en bordure de fenêtre ; la fenêtre glissante neutralise ces effets de bord ; le token bucket, enfin, autorise des pics contrôlés tout en bornant le débit moyen. L'essentiel est d'appliquer les limites par identité authentifiée, client, utilisateur, agent, plutôt que par adresse IP, facilement contournable.

Le rate limiting ne suffit toutefois plus : les attaques qui respectent les quotas mais abusent de la logique métier, énumération d'identifiants, parcours d'achat détournés, exigent une détection comportementale à la gateway ou au WAAP, croisant signaux de trafic et contexte applicatif.

Les API GraphQL méritent un traitement spécifique : une seule requête peut déclencher une charge considérable par imbrication de champs. Limiter la profondeur et la complexité des requêtes, plafonner le coût calculé de chaque appel et désactiver l'introspection en production font partie du socle minimal pour ce style d'API.

@cite:devsecops-10-bonnes-pratiques

SECTION 5

Gouvernance : inventaire, contrat d'API et sécurité en CI/CD

On ne protège pas ce qu'on ignore : les shadow APIs, déployées hors des processus officiels, et les zombie APIs, d'anciennes versions jamais décommissionnées, figurent parmi les premières causes d'incident. Un inventaire continu, alimenté par la découverte automatique à partir du trafic réel, est le préalable de toute stratégie de sécurité API.

### Le contrat OpenAPI comme point de contrôle

La spécification OpenAPI de chaque API devient un point de contrôle : linting sécurité en CI pour détecter les schémas trop permissifs, validation des requêtes et réponses à la gateway pour rejeter tout ce qui sort du contrat, tests de sécurité dynamiques rejoués à chaque déploiement. La gateway centralise l'authentification, l'autorisation et la télémétrie, pour que chaque équipe n'ait pas à réinventer ces briques critiques.

La gouvernance couvre enfin tout le cycle de vie : versionnage explicite, politique de dépréciation communiquée aux consommateurs et décommissionnement effectif des anciennes versions, mesuré, pas seulement annoncé. Une API retirée du portail développeur mais toujours joignable en production reste une porte d'entrée pour un attaquant, avec l'aggravation de n'être plus ni surveillée ni corrigée.

Cette hygiène outillée se complète de vérifications adverses : tests d'intrusion ciblés sur les API les plus critiques, campagnes de fuzzing sur les entrées pour débusquer les cas limites que les tests fonctionnels ignorent, et programmes de divulgation responsable qui canalisent les découvertes des chercheurs externes. L'objectif est de confronter régulièrement le dispositif à des conditions réelles d'attaque plutôt que de se fier aux seuls contrôles automatisés, les attaquants, eux, ne se limitent pas au périmètre déclaré dans le contrat.

@cite:api-design-rest-vs-graphql-et-au-dela

SECTION 6

Sécuriser les API face aux agents IA et au protocole MCP

Une nouvelle catégorie de consommateurs a émergé : les agents IA, qui appellent les API de l'entreprise en autonomie, souvent via le protocole MCP (Model Context Protocol). Environ la moitié des développeurs citent les appels d'API non autorisés par des agents et la fuite d'identifiants liée aux intégrations IA parmi leurs premières inquiétudes, à raison : un agent sur-privilégié peut enchaîner en quelques secondes des actions qu'aucun utilisateur humain n'aurait réalisées.

Les contre-mesures existent et rejoignent les fondamentaux : une identité machine dédiée par agent, jamais d'identifiants humains partagés ; des scopes étroits et des tokens à durée de vie courte, alignés sur la tâche à accomplir ; une validation humaine pour les actions irréversibles ; et une journalisation systématique qui distingue le trafic agentique du trafic humain pour l'audit et la détection d'anomalies. Enfin, des limites de débit spécifiques au trafic agentique, plus strictes que celles des utilisateurs humains, contiennent l'impact d'un agent qui s'emballe.

Le protocole MCP lui-même converge vers ces standards : sa spécification d'autorisation s'appuie sur OAuth 2.1, ce qui permet d'appliquer aux serveurs MCP les mêmes exigences qu'à n'importe quelle API, enregistrement des clients, scopes explicites, tokens à courte durée de vie. Traiter un serveur MCP comme une API à part entière, soumise aux mêmes contrôles et au même inventaire, est la position la plus sûre.

@cite:les-agents-ia-ne-doivent-pas-etre-un-cauchemar-de-securite

SECTION 7

L'approche Adservio : la sécurité API conçue en amont

Chez Adservio, nous abordons la sécurité des API comme un ensemble cohérent plutôt que comme une somme de correctifs ponctuels : autorisation moderne, tokens résistants au vol, maîtrise du débit, gouvernance du cycle de vie et encadrement des consommateurs IA forment un socle qui se pense dès la conception, dans une logique DevSecOps.

Notre conviction : une API bien protégée est une API dont la sécurité a été conçue en amont, pas rajoutée après coup. Nous accompagnons vos équipes dans la mise en place de ces pratiques, de l'audit initial à l'outillage en CI/CD, et leur transférons la maîtrise pour qu'elles maintiennent durablement un niveau de sécurité élevé.

Cette démarche s'appuie sur des jalons mesurables : couverture de l'inventaire, part des API conformes à OAuth 2.1, latence de révocation d'un token compromis, délai de détection d'un comportement anormal. La sécurité des API se pilote comme la fiabilité : par des indicateurs suivis dans la durée, pas par des audits ponctuels.

FAQ

Questions fréquentes