API security

01 — DéfinitionQu'est-ce que l'API security ?

L'API security (sécurité des API) est la discipline de la cybersécurité qui vise à protéger les interfaces de programmation contre les abus, fuites de données et attaques. Elle combine plusieurs dimensions :

• Inventaire et découverte : savoir quelles API existent réellement dans l'organisation.
• Contrôles d'accès : authentification, autorisation, gestion des tokens.
• Validation des entrées : schémas, types, bornes, filtrage.
• Limitation de débit : rate limiting, quotas, protection contre l'abus.
• Chiffrement des échanges : TLS, mTLS.
• Surveillance comportementale : détection des usages anormaux.
• Tests de sécurité dédiés : SAST, DAST API, fuzzing.
• Gouvernance : standards, revue, cycle de vie.

Types d'API concernées

• REST : le plus courant, sur HTTP/HTTPS, avec URI identifiant les ressources.
• GraphQL : requêtes flexibles côté client, défis spécifiques (introspection, query complexity).
• SOAP : historique, XML-based, toujours présent dans les environnements legacy et financiers.
• gRPC : moderne, haute performance, utilisé en interne microservices.
• WebSocket : communications bidirectionnelles, défis en détection.
• API messaging (Kafka, RabbitMQ, AMQP) : moins directement exposées mais toujours à sécuriser.

Pourquoi un champ distinct de la sécurité web ?

L'API security partage des fondations avec la sécurité web traditionnelle (OWASP Top 10) mais présente des spécificités :

• Les API exposent souvent directement la logique métier, sans couche de présentation intermédiaire qui pourrait filtrer.
• Les identifiants de ressources sont souvent devinables (incréments numériques), exposant au BOLA.
• Les API sont consommées par des clients non contrôlés (applications mobiles, partenaires, intégrations tierces) — impossible de faire confiance au client.
• La volumétrie est telle qu'une protection manuelle n'est pas envisageable.
• Les API souvent bien documentées (OpenAPI) sont des cibles claires pour attaquants.
• Les réponses API retournent souvent plus de données que nécessaire (problème d'excessive data exposure).

Une API n'est pas juste « une page web sans interface ». C'est une surface d'attaque structurée, documentée, machinable à grande échelle, où chaque endpoint est une porte potentielle. Les hypothèses implicites de la sécurité web (un humain derrière un navigateur, une session, un canal visuel) n'y tiennent plus.

02 — PourquoiUn enjeu devenu critique

Explosion quantitative

Les études sectorielles 2024-2025 (Akamai, Salt Security, Gartner) convergent :

• 80 % et plus du trafic Internet est désormais du trafic API.
• Une entreprise moyenne expose plusieurs centaines à milliers d'API, souvent sans inventaire exhaustif.
• Le nombre d'API double environ tous les 2-3 ans dans les organisations en transformation digitale.
• Plus de 90 % des attaques applicatives ciblent désormais les API plutôt que les interfaces web classiques (source : Gartner).

Facteurs structurels

Architectures cloud-natives

Microservices, containers, Kubernetes : chaque composant communique par API. Un service historique monolithique devient des dizaines de microservices exposant chacun leurs endpoints.

Mobile-first et front-end modernes

Les applications mobiles et SPA (Single Page Applications) reposent quasi-exclusivement sur des API backend. La logique métier historiquement confinée au serveur web est désormais exposée directement.

Open banking et PSD2

La directive européenne DSP2 / PSD2 impose aux banques d'ouvrir des API à des acteurs tiers. Extension prévue avec PSD3 et FIDA (Financial Data Access Regulation). Exposition massive et standardisée de données financières.

Intégrations SaaS et plateformes

Les écosystèmes SaaS (Salesforce, ServiceNow, Workday…), les marketplaces API (RapidAPI), les intégrations inter-SaaS via Zapier, Make, Workato génèrent un nombre exponentiel de flux API.

Intelligence artificielle

Les services d'IA générative (OpenAI, Anthropic, Mistral, Google, Azure OpenAI) sont consommés par API. Les agents IA, les fonctions tool use, le MCP (Model Context Protocol) génèrent une surface supplémentaire avec ses propres défis.

Sophistication des attaquants

Les attaquants adaptent leurs outillages aux API :

• Énumération automatisée des endpoints via fichiers OpenAPI accessibles.
• Fuzzing ciblé sur les schémas connus.
• Attaques BOLA par incrémentation d'identifiants.
• Exploitation de secrets, tokens et clés API trouvés dans des dépôts publics.
• Credential stuffing contre les endpoints d'authentification API, moins souvent protégés par MFA qu'une interface web.
• Détournement de quotas pour scraper des données massivement.

Conséquences observées

• Fuites de données massives : T-Mobile (2023, 37 millions de clients), Optus (2022, 10 millions), Peloton (2021).
• Scraping à grande échelle : LinkedIn (2021, 700 millions de profils), Twitter (2022, 200+ millions), Facebook (2021, 530 millions).
• Fraude financière : abus d'API de paiement, détournement de fonctionnalités.
• Abus de services : sur-consommation d'API tierces génératrice de coûts.
• Sanctions RGPD : Meta, Uber, Clearview AI ont été sanctionnés pour des failles impliquant des API.

03 — OWASP API Top 10Les 10 risques majeurs 2023

L'OWASP API Security Top 10 est le référentiel mondial des risques API. Première édition en 2019, mise à jour majeure en 2023. Toute démarche API security sérieuse s'y réfère.

API1:2023 — Broken Object Level Authorization (BOLA)

Vulnérabilité numéro 1, largement la plus répandue. L'API authentifie l'utilisateur mais ne vérifie pas qu'il est autorisé à accéder à l'objet précis demandé. Exemple : /api/orders/12345 retourne la commande sans vérifier qu'elle appartient au demandeur. Les attaquants énumèrent les identifiants pour extraire massivement des données.

Prévention : contrôle d'accès objet par objet côté serveur, validation systématique de la propriété, identifiants opaques (UUID v4 aléatoires plutôt qu'incréments), tests dédiés.

API2:2023 — Broken Authentication

Défauts dans les mécanismes d'authentification : gestion faible des tokens, secrets exposés, absence de MFA sur les endpoints critiques, tokens à durée excessive, revocation défaillante, bruteforce possible sur endpoints de connexion.

Prévention : OAuth 2.0 / OIDC standards, MFA partout où pertinent, gestion rigoureuse du cycle de vie des tokens, protection contre le bruteforce, passkeys quand possible.

API3:2023 — Broken Object Property Level Authorization

Nouveau dans la version 2023. Combine les anciens Excessive Data Exposure et Mass Assignment. L'API expose ou permet de modifier des propriétés d'objets qui ne devraient pas être accessibles : champs admin, rôles, statuts, données internes.

Prévention : allowlist des propriétés retournées et modifiables, schémas de réponse stricts, ségrégation des DTO (Data Transfer Objects) par contexte.

API4:2023 — Unrestricted Resource Consumption

Absence de limitations sur la consommation de ressources : rate limiting insuffisant, requêtes coûteuses non bornées, pagination absente, fichiers volumineux, GraphQL sans limite de complexité. Conséquences : déni de service, coûts cloud explosifs, scraping massif.

Prévention : rate limiting par IP, utilisateur, clé API ; quotas, timeout, pagination obligatoire, limite de profondeur/complexité GraphQL, validation des tailles d'upload.

API5:2023 — Broken Function Level Authorization

L'API vérifie l'authentification mais pas le droit d'accéder à une fonction spécifique : utilisateur standard accédant à un endpoint admin, escalade de privilèges horizontale ou verticale.

Prévention : contrôle d'autorisation sur chaque endpoint, principe de moindre privilège, tests systématiques des matrices de droits.

API6:2023 — Unrestricted Access to Sensitive Business Flows

Nouveau. Certains flux métier (achat de billets, création de comptes, concours) peuvent être détournés par automatisation sans violation technique : scalping, création massive de faux comptes, exploitation de codes promo.

Prévention : détection comportementale, CAPTCHA adaptatifs, limites métier, analyse des patterns d'usage, protection anti-bot moderne.

API7:2023 — Server Side Request Forgery (SSRF)

L'API accepte une URL fournie par l'utilisateur et va la requêter côté serveur. Permet à l'attaquant d'accéder à des ressources internes (services métadonnées cloud, services internes non exposés). Particulièrement dangereux dans les environnements AWS, Azure, GCP où les métadonnées d'instance exposent des credentials.

Prévention : allowlist stricte des destinations, blocage des plages IP internes et services métadonnées, proxy dédié pour les requêtes sortantes.

API8:2023 — Security Misconfiguration

Configurations par défaut, headers de sécurité manquants, CORS trop permissif, messages d'erreur divulguant des informations, pages de debug en production, versions vulnérables.

Prévention : configurations durcies par défaut, revue avant mise en production, monitoring des dérives de configuration, tests automatisés.

API9:2023 — Improper Inventory Management

API non recensées (shadow API), versions obsolètes toujours en production (zombie API), documentation incomplète ou non à jour, environnements hors production accessibles.

Prévention : inventaire automatique (découverte par observation du trafic), registry des API, cycle de vie formalisé, processus de décommissionnement.

API10:2023 — Unsafe Consumption of APIs

Nouveau. L'API consomme des API tierces sans précaution : fait confiance aux données reçues, suit les redirections sans validation, accepte des certificats invalides.

Prévention : validation stricte des réponses tierces, vérification des certificats, limitation des intégrations, traçabilité des flux sortants.

04 — IncidentsCas historiques marquants

T-Mobile — 37 millions de clients (janvier 2023)

L'opérateur américain a déclaré qu'un attaquant avait utilisé une API mal protégée pour extraire les données de 37 millions de clients (noms, emails, numéros de téléphone, dates de naissance, numéros de comptes). L'exploitation a duré plusieurs semaines avant détection. Archétype de BOLA à grande échelle.

Optus — 10 millions de clients (septembre 2022)

L'opérateur télécom australien a exposé les données de près de 10 millions de clients via une API non authentifiée, accessible directement sur Internet avec des identifiants incrémentaux. L'un des plus gros incidents cyber de l'histoire australienne. Coûts estimés : centaines de millions de dollars.

Peloton — accès à tout compte (2021)

L'API du fabricant de vélos connectés permettait d'accéder aux données de n'importe quel utilisateur avec son ID : nom, genre, poids, statistiques d'entraînement. Vulnérabilité signalée à Peloton par un chercheur de Pen Test Partners, initialement ignorée, puis corrigée après pression médiatique.

Parler — exfiltration complète (janvier 2021)

Avant son bannissement des app stores, le réseau social Parler exposait une API avec identifiants numériques séquentiels. Des chercheurs ont téléchargé l'intégralité des posts et vidéos publiques — plusieurs dizaines de téraoctets — en quelques heures.

Coinbase — bug critique (février 2022)

Bug dans l'API de trading qui permettait de vendre des actifs qu'on ne possédait pas. Signalé via bug bounty, Coinbase a versé 250 000 $ de récompense. Démonstration de l'intérêt des programmes de divulgation responsable.

LinkedIn scraping — 700 millions (2021)

Des données de 700 millions d'utilisateurs LinkedIn ont été extraites via abus d'API publiques et intégrations. LinkedIn a qualifié l'incident de scraping massif plutôt que violation, mais les conséquences pour les utilisateurs (phishing ciblé ultérieur) sont réelles.

Twitter — vulnérabilité API (2022)

Bug dans l'API Twitter permettant de savoir si une adresse email ou numéro de téléphone était associé à un compte Twitter. Exploité à grande échelle : 200+ millions d'emails mis en vente. Twitter a été sanctionné par la DPC irlandaise.

Uber — scripts d'admin exposés (2022)

L'attaquant a combiné ingénierie sociale, MFA fatigue et accès à des scripts internes pour obtenir des credentials admin via des API internes. Démonstration qu'un contrôle d'accès interne laxiste sur des API est aussi dangereux que l'exposition externe.

Enseignements

• Les BOLA et défauts d'authentification dominent largement.
• Les incidents majeurs ne viennent pas de vulnérabilités exotiques mais de contrôles basiques mal implémentés.
• La détection est souvent tardive — plusieurs semaines à plusieurs mois.
• Les volumétries exfiltrées sont énormes dès que l'API est automatisable.
• Le coût réputationnel dépasse souvent le coût technique.
• Les programmes de bug bounty permettent de détecter nombre de ces failles avant qu'elles ne soient exploitées.

05 — OutillageFamilles de solutions API security

Plateformes de sécurité API dédiées

Nouvelle catégorie structurée autour de la découverte, la détection comportementale et la protection runtime des API.

• Salt Security : pionnier et leader du marché, forte capacité de découverte et analyse comportementale.
• Noname Security : acquis par Akamai en 2024, désormais intégré dans l'offre Akamai API Security.
• Wallarm : plateforme combinant WAF et API security.
• Cequence Security : forte capacité anti-bot et anti-abuse.
• Traceable AI : observabilité et sécurité API avec approche distributed tracing.
• Data Theorem : API + mobile + cloud combinés.
• Imperva API Security : intégration dans la suite Imperva.
• F5 Distributed Cloud API Security : intégration dans l'écosystème F5.

Outils de test et audit API

• 42Crunch : leader de l'audit OpenAPI, scoring automatique, intégré CI/CD.
• APIsec : testing API automatisé.
• StackHawk : DAST moderne, orienté API et CI/CD.
• Burp Suite avec extensions API : référence manuelle pour pentesters.
• OWASP ZAP avec import OpenAPI : gratuit, efficace.
• Postman Security : scans intégrés à l'outil de développement.
• Nuclei : scanner rapide, templates pour API.
• RESTler (Microsoft) : fuzzer API open source.

API Gateways avec fonctions sécurité

Point de contrôle naturel pour appliquer des politiques de sécurité de base.

• Kong Enterprise : leader open source + offre commerciale.
• Apigee (Google Cloud) : suite enterprise mature.
• AWS API Gateway : natif AWS, intégration Cognito, WAF.
• Azure API Management : équivalent Azure.
• MuleSoft Anypoint : Salesforce, orientation intégration.
• Tyk : alternative open source.
• WSO2 API Manager : open source complet.

WAF et protections en bordure

• Cloudflare API Gateway / API Shield : intégré à l'écosystème CDN Cloudflare.
• AWS WAF : règles spécifiques API.
• Akamai API Security (ex-Noname) : intégration edge.
• Azure Front Door / Application Gateway avec WAF.
• Fastly : protections API en edge.

Gestion des identités et tokens

• Auth0 (Okta) : plateforme historique.
• Microsoft Entra ID (ex-Azure AD) : natif Microsoft.
• Keycloak : open source, self-hosted.
• Ory : stack identity open source moderne.
• Curity : spécialisé OAuth avancé.
• WorkOS, Authlete, FusionAuth : autres acteurs.

Outils open source utiles

• Kong Insomnia et Postman : tests manuels et collections.
• mitmproxy : proxy d'interception, inspection trafic API.
• openapi-diff : détection de breaking changes.
• spectral : linter OpenAPI.
• graphql-shield, GraphQL Armor : protection spécifique GraphQL.

06 — Bonnes pratiquesSécuriser les API du code à la production

07 — GouvernanceMaturité organisationnelle

Niveaux de maturité API security

Niveau 1 — Réactif

• Aucun inventaire exhaustif des API.
• Authentification et autorisation gérées au cas par cas par les équipes de développement.
• Détection et remédiation post-incident uniquement.
• Majorité des PME et organisations peu matures.

Niveau 2 — En cours de structuration

• Inventaire officiel existant mais incomplet.
• Standards d'authentification définis (OAuth 2.0) mais application inégale.
• WAF et API Gateway en place avec règles génériques.
• Tests de sécurité API ponctuels.
• La plupart des ETI et scale-ups.

Niveau 3 — Mature

• Découverte automatique des API via plateforme dédiée.
• Standards appliqués systématiquement, revues obligatoires.
• Tests automatisés dans CI/CD.
• Monitoring comportemental en production.
• Gouvernance du cycle de vie complète.
• Grandes entreprises et secteurs régulés.

Niveau 4 — Optimisé

• API security intégrée dans la culture d'ingénierie.
• Métriques suivies et publiées (MTTR, couverture, incidents).
• Threat modeling systématique.
• Contribution à la communauté (rapports, recherche, standards).
• Pure players tech, grands groupes les plus avancés.

Rôles impliqués

• Architectes API : définissent standards et référentiels.
• Équipes produit et dev : implémentent les API et les contrôles.
• AppSec / Security Champions : accompagnent les équipes.
• Équipe plateforme : opère gateways et WAF.
• SOC analysts : détectent et répondent aux incidents runtime.
• Pentesters : testent manuellement les API critiques.
• DPO : veille à la protection des données personnelles.
• RSSI : pilote stratégique.

Articulation avec les référentiels

• ISO 27001 : la version 2022 inclut des contrôles sur le développement sécurisé applicables aux API.
• SOC 2 : critères de sécurité et confidentialité couvrent les API.
• PCI DSS : 4.0 renforce les exigences sur les API de paiement.
• RGPD : une fuite via API est une violation de données.
• NIS2 : gestion de la chaîne d'approvisionnement inclut les API consommées.
• DORA : obligations sur les API ouvertes du secteur financier.
• CRA : produits avec API intégrées soumis à des obligations cybersécurité.

Métriques clés à suivre

• Couverture de l'inventaire : % d'API découvertes correspondant à l'inventaire officiel.
• Shadow/zombie API ratio : écart entre déclaré et observé.
• API avec schéma OpenAPI à jour : %.
• API couvertes par MFA quand pertinent.
• API testées (SAST/DAST) dans les 30 derniers jours.
• MTTR sur vulnérabilités API par criticité.
• Incidents API par période, par type.
• Rate limiting actif : % d'endpoints avec limites configurées.

08 — FAQQuestions fréquentes

Un WAF classique suffit-il pour protéger les API ?

Non. Les WAF traditionnels protègent bien contre les attaques connues (injections SQL, XSS, patterns OWASP web classique) mais sont aveugles aux vulnérabilités spécifiques API comme le BOLA, qui ne se distinguent pas des requêtes légitimes au niveau réseau. Un utilisateur authentifié qui accède séquentiellement aux URLs /api/orders/1, /api/orders/2, /api/orders/3… est techniquement correct mais exfiltre des données. Seule la compréhension métier et la détection comportementale (plateforme API security dédiée ou logique applicative spécifique) peuvent l'identifier. Un WAF reste utile mais insuffisant : il faut le combiner avec des contrôles applicatifs et une détection comportementale.

Les API internes doivent-elles aussi être sécurisées ?

Oui, et c'est une erreur fréquente de considérer qu'une API interne est protégée par le simple fait d'être dans le réseau. Le modèle Zero Trust postule qu'il n'y a pas de « zone de confiance » : un attaquant qui compromet un poste via phishing ou qui s'introduit par mouvement latéral dispose du même accès aux API internes qu'un service légitime. Les cas Uber, Coinbase, Twilio ont montré l'impact d'API internes mal protégées. Les bonnes pratiques : authentification service-to-service (mTLS, OAuth client credentials), segmentation réseau, journalisation, mêmes contrôles d'autorisation que les API externes.

GraphQL est-il plus ou moins sécurisé que REST ?

Ni plus ni moins sécurisé intrinsèquement, mais avec des défis différents. Avantages GraphQL : schéma fortement typé, introspection qui facilite la documentation. Défis spécifiques GraphQL : requêtes très complexes possibles (denial of service par complexité), introspection qui facilite aussi la reconnaissance pour les attaquants, batching qui complique le rate limiting, pattern de résolveurs qui peut masquer des contrôles d'accès. Bonnes pratiques spécifiques : limite de profondeur et de complexité, coût par résolveur, désactivation de l'introspection en production (au moins pour utilisateurs non authentifiés), utilisation de bibliothèques comme GraphQL Armor ou graphql-shield.

Combien coûte la mise en place de l'API security ?

Variable selon la taille et le niveau de maturité visé. Fourchettes indicatives pour une ETI :

• Niveau 1 à 2 : utiliser les capacités natives de l'API Gateway et du WAF existants, ajouter 42Crunch ou équivalent pour le scan. 20 000 à 60 000 € par an en licences + 2-3 mois d'intégration.
• Niveau 2 à 3 : plateforme API security dédiée (Salt, Noname/Akamai, Traceable). 100 000 à 300 000 € par an selon volumétrie + projet d'intégration de 6-12 mois.
• Niveau 3 à 4 : plateforme dédiée + équipe spécialisée + testing continu + bug bounty. 500 000 € à plusieurs millions par an pour les grands groupes.

Le ROI se mesure contre les coûts évités (incidents, amendes RGPD jusqu'à 4 % du CA mondial, perte de confiance). Un seul incident majeur coûte généralement plus que plusieurs années de prévention.

Les API d'IA générative posent-elles des risques spécifiques ?

Oui, plusieurs nouveaux risques s'ajoutent. Prompt injection : un attaquant injecte des instructions dans les données envoyées à l'IA pour détourner son comportement. Fuites de données : les API IA peuvent retourner des données issues des entraînements ou des contextes d'autres utilisateurs si la segmentation est défaillante. Consommation excessive : coûts d'API OpenAI ou équivalent peuvent exploser en cas d'abus. Exfiltration via LLM : un attaquant peut utiliser une API IA connectée à des données sensibles pour extraire ces données par questions détournées. Le référentiel OWASP LLM Top 10 (publié en 2023) complète l'OWASP API Top 10 pour ces enjeux spécifiques. Les plateformes AI security (Lakera, Protect AI, Robust Intelligence) émergent en réponse.