Pourquoi les API sont attaquées - Les raisons et les conséquences

Les API (Application Programming Interfaces) sont devenues en 10 ans le tissu conjonctif des systèmes modernes. Chaque application mobile, chaque SaaS, chaque intégration partenaire, chaque microservice communique via des API. Cette omniprésence les transforme en première surface d'attaque : selon Gartner, les attaques ciblant les API sont devenues en 2022 le vecteur dominant d'incidents applicatifs, et leur volume continue à croître de 30 à 40 % par an. Ce guide explique pourquoi les API concentrent désormais le risque, quels sont les cas emblématiques, et pourquoi les défenses classiques (WAF, pentest web) ne suffisent pas.

1. L'explosion de la surface API

1.1 Quelques chiffres

Les études 2023-2025 (Akamai, Salt Security, Cloudflare, Postman, Kong) convergent :

• 83 % du trafic web en 2024 est du trafic API (vs pages HTML).
• Une entreprise moyenne expose entre 300 et 5 000 API en production.
• 31 % des entreprises découvrent périodiquement des shadow APIs (non inventoriées).
• 17 % des API exposées en prod n'ont aucune authentification.
• Les attaques ciblant les API ont crû de 117 % en 2023 sur 2022 (Akamai State of the Internet).

L'API n'est plus un canal technique parmi d'autres : c'est le canal, avec toutes les conséquences en termes de risque.

1.2 Pourquoi cette explosion

Quatre ruptures techniques depuis 2010 ont multiplié les API :

• Mobile first : chaque app mobile est un client API. Où une app web classique pouvait opérer en server-side rendering, le mobile oblige à exposer une API pour tout.
• Single Page Applications (React, Vue, Angular) : le front-end consomme des API pour tout, y compris la logique métier qui était auparavant côté serveur.
• Microservices : un monolithe devient 20 à 50 services, chacun exposant son API interne (souvent accessible à d'autres services sans auth stricte).
• SaaS et économie API-first : Stripe, Twilio, Plaid, Algolia, Auth0 — l'entreprise moderne est l'intégration de dizaines d'API tierces.

Conséquence : la surface d'attaque API a été multipliée par 10 à 50 en une décennie, sans que les pratiques sécurité n'aient suivi à la même cadence.

2. Ce qui rend les API spécifiquement attaquables

2.1 Exposition directe de la logique métier

Une application web classique (server-side rendering) ne révèle au client que du HTML rendu. La logique métier et la structure de données restent côté serveur, protégées par l'abstraction.

Une API expose directement :

• Les objets métier (JSON de user, order, invoice).
• Les identifiants internes (IDs utilisateurs, order_id numériques séquentiels).
• Les actions possibles (endpoints nommés par ressource/action).
• Les schémas de données (souvent documentés via OpenAPI).

Un attaquant découvre l'architecture applicative rien qu'en lisant les appels API. La courbe d'apprentissage avant exploitation est drastiquement réduite.

2.2 Les identifiants dans l'URL

L'essor du REST a conduit à des URLs type /api/users/12345/orders/67890. Chaque ressource a son ID exposé. Si l'application ne vérifie pas côté serveur que l'utilisateur authentifié a bien le droit d'accéder à users/12345/orders/67890, un attaquant peut tester users/12346, users/12347, etc.

Cette vulnérabilité - BOLA (Broken Object Level Authorization) - est le N°1 de l'OWASP API Top 10 depuis 2019. Elle est catastrophiquement fréquente : selon les pentests Salt Security, plus de 40 % des API testées présentent au moins un endpoint vulnérable à BOLA.

2.3 Les schémas documentés publiquement

Les bonnes pratiques encouragent à publier un fichier OpenAPI / Swagger décrivant les endpoints, les paramètres, les schémas de données. Utile pour les intégrateurs... et pour les attaquants : ils obtiennent gratuitement la cartographie complète de la surface à tester.

Les scanners automatisés comme Akto, 42Crunch, Burp Suite ingèrent les OpenAPI pour générer des millions de requêtes ciblées.

2.4 L'absence de WAF adapté

Les WAF classiques (ModSecurity, AWS WAF, Cloudflare WAF) sont conçus pour le trafic web HTML traditionnel. Leurs règles OWASP CRS détectent XSS, SQLi basiques, path traversal. Elles sont peu efficaces contre :

• BOLA (accès à un objet autorisé par authN mais pas authZ).
• BFLA (abus d'un endpoint admin par un user standard).
• Mass assignment (injection d'attributs non prévus).
• Rate abuse (scraping massif dans les limites nominales).
• Logic abuse (séquence d'appels légitimes utilisés de façon pathologique).

Ces attaques passent invisibles aux yeux d'un WAF : chaque requête est syntaxiquement valide, authentifiée, et conforme au schéma.

2.5 Auth légère et tokens long-lived

Beaucoup d'API exposent des endpoints avec :

• API keys statiques qui ne tournent jamais.
• Tokens JWT avec durée de vie très longue (90 jours, 1 an, parfois pas d'expiration).
• Cookies session sans SameSite, sans HttpOnly, sans Secure.
• No authentication sur des endpoints "internes" qui finissent exposés.

Un token volé reste utilisable souvent pendant des mois.

2.6 Absence d'inventaire

La question la plus déstabilisante à poser à une équipe : "Combien d'API avez-vous en production, exactement ?" Dans 80 % des cas, la réponse est approximative.

• Shadow API : API créée par une équipe sans passer par la gouvernance.
• Zombie API : ancienne version restée active après déploiement d'une nouvelle.
• Rogue API : endpoint de test/debug oublié en prod.

Sans inventaire, la défense est aveugle. Un attaquant qui découvre une API shadow a toutes les chances d'y trouver des contrôles moins stricts que sur les API officielles.

3. Les incidents emblématiques 2019-2024

3.1 Venmo (2018) - transactions publiques par API

Une API Venmo retournait par défaut toutes les transactions publiques sans rate limiting. Un chercheur a scrapé 200 millions de transactions en quelques semaines, révélant des motifs comportementaux massivement sensibles (drogue, prostitution, dépendances). Leçon : paramètres par défaut sont un choix de design sécurité.

3.2 USPS (2018) - accès aux données de 60M clients

Une API interne exposée sans restriction sur le site USPS permettait à n'importe quel utilisateur authentifié de récupérer les données personnelles de tous les autres clients USPS. 60 millions de records accessibles via modification d'ID. BOLA de manuel.

3.3 Peloton (2021) - données de 3M users

Un endpoint API Peloton acceptait de retourner les données d'un utilisateur même si le requester n'était pas authentifié (endpoint oublié en mode "public"). Age, sexe, poids, ville, historique d'entraînement de 3 millions d'utilisateurs récupérables par un script simple. Broken Authentication classique.

3.4 T-Mobile (2022-2023) - 37 millions de clients

Une API T-Mobile destinée aux intégrations partenaires n'avait pas de rate limiting adapté. Un attaquant a pu requêter massivement sur plusieurs semaines, récupérant informations personnelles de 37 millions de clients (nom, date de naissance, contact, détails comptes). Amende FCC : 350 millions USD.

3.5 Twitter/X (2022) - 5,4M users exposés

Un bug dans une API Twitter permettait, à partir d'un email ou d'un numéro de téléphone, de retrouver le compte Twitter associé. Exploité massivement pour construire une base de données de 5,4 millions d'utilisateurs liés à leurs contacts personnels. Vendue sur forums criminels.

3.6 Optus (Australie, 2022) - 10M de clients

L'opérateur télécom australien Optus avait une API "public" accessible sans authentification exposant des données clients. Un attaquant a exfiltré les données de 10 millions de clients australiens (40 % de la population). Le CEO a témoigné devant le parlement. Amende et class action en cours.

3.7 Dell (mai 2024) - 49M de clients

Un attaquant a enregistré de faux partenaires Dell, obtenant accès à l'API partenaires avec faible contrôle d'identité. Il a ensuite scrapé 49 millions de records clients sur plusieurs semaines sans déclencher d'alerte. Broken Authentication + Rate Limiting + Inventory failure combinés.

3.8 Schéma récurrent

Aucune de ces fuites ne nécessite une 0-day. Aucune n'utilise un exploit sophistiqué. Toutes reposent sur :

• BOLA ou Broken Authentication évidents.
• Absence de rate limiting.
• Pas d'inventaire ni monitoring API spécifique.
• Données sensibles renvoyées par défaut sans minimisation.

Les attaquants exploitent des erreurs de design, pas des failles techniques cachées. C'est ce qui rend les API si attaquables, et si difficiles à défendre avec les outils classiques.

4. L'OWASP API Security Top 10 (version 2023)

OWASP maintient depuis 2019 un Top 10 dédié aux API, mis à jour en 2023 pour refléter l'évolution des patterns.

Chaque item est un symptôme d'un design fragile. Les 5 premiers (BOLA, Broken Auth, BOPLA, Resource Consumption, BFLA) concentrent typiquement 80 % des incidents réels.

5. Les patterns d'attaque modernes spécifiques aux API

5.1 BOLA (authz horizontale)

L'attaquant modifie un ID dans l'URL ou le body pour accéder à l'objet d'un autre utilisateur. Exemple :

• Légitime : GET /api/invoices/78901 (ma facture).
• Attaque : GET /api/invoices/78902 → facture d'un autre client.

Mitigation : vérifier côté serveur à chaque requête que l'utilisateur est autorisé sur l'objet demandé, pas juste authentifié.

5.2 BFLA (authz verticale)

L'attaquant accède à une fonction réservée aux admins en devinant l'URL ou le paramètre.

• Légitime user : GET /api/users/me (mon profil).
• Attaque : GET /api/admin/users → liste tous les users, sans vérification du rôle admin.

Mitigation : vérifier le rôle à chaque requête, middleware d'autorisation centralisé.

5.3 Mass assignment

L'attaquant injecte des attributs non prévus dans un body JSON.

• Endpoint prévu : PUT /api/users/me avec body {"name": "Jean"}.
• Attaque : PUT /api/users/me avec body {"name": "Jean", "role": "admin", "is_verified": true}.

Si le framework fait du parsing automatique sans whitelist (ORM avec fill(), Django .save() avec instance populated from request.data), l'attaquant devient admin.

Mitigation : whitelist explicite des attributs acceptés (DTO, serializers avec fields explicites).

5.4 API scraping massif

L'attaquant utilise des API légitimes au maximum de leur capacité pour exfiltrer en masse :

• Énumération d'utilisateurs via endpoint de recherche.
• Dump de catalogue via endpoint de listing avec pagination maxée.
• Énumération séquentielle d'IDs exposés.

Pratiqué par les data brokers criminels et concurrents malveillants. Sans rate limiting intelligent (par user, par IP, par endpoint, avec détection de pattern), invisible.

5.5 Business logic abuse

L'attaquant exécute des flows techniquement valides dans un ordre ou à une fréquence pathologique :

• Achat de coupons promo en masse par script.
• Réservation et annulation en boucle pour bloquer un créneau concurrent.
• Création de comptes jetables pour abuser des crédits d'essai.
• Vote automatisé dans un sondage.

Aucune vulnérabilité technique classique. Seule la compréhension métier permet de détecter.

5.6 GraphQL introspection et abuse

GraphQL par défaut expose le schéma complet via introspection : un attaquant connaît toute l'API en une requête. De plus :

• Query de grande profondeur : query { user { friends { friends { friends { ... } } } } } fait exploser le coût serveur (DoS).
• Alias multiples : même query répétée N fois dans une requête pour contourner le rate limiting par requête.
• Field duplication : récupérer des sensitive fields sous des alias.

Mitigations : query depth limit, query complexity analysis, disable introspection en production, rate limiting par query cost.

5.7 SSRF via API

Une API qui accepte une URL en paramètre (ex. POST /api/webhooks avec {"url": "https://..."}) peut être abusée pour forcer le serveur à appeler des URL internes : http://169.254.169.254/ (IMDS AWS), http://localhost:8500/ (Consul), etc.

Voir c'est quoi une vulnérabilité SSRF pour les détails.

5.8 API abuse via bots et automation

Au-delà des attaques "techniques", l'abuse business via bots :

• Account takeover via credential stuffing sur endpoint login.
• Card cracking (test de numéros de carte volés).
• Scalping (achat automatisé de stocks limités).
• Ad fraud (clics simulés).
• Fake account creation massive.

Les WAF traditionnels ne détectent pas. Besoin de bot management spécialisé (DataDome, Imperva Advanced Bot Protection, Cloudflare Bot Management).

6. Pourquoi les défenses traditionnelles échouent

6.1 WAF classique

Conçu pour détecter XSS, SQLi, path traversal dans des requêtes web HTML. Peu adapté aux attaques API :

• Ne comprend pas la sémantique OpenAPI.
• Pas de contexte métier (qui peut accéder à quoi).
• Règles basées sur signatures statiques, contournables.

Évolution : catégorie WAAP (Web Application and API Protection) qui étend le WAF avec schema validation, rate limiting granulaire, bot detection. Leaders : Cloudflare, F5, Imperva, Akamai, Fastly.

6.2 Pentest web classique

Un pentest web traditionnel teste :

• Une liste d'URLs "visibles" via crawling.
• Des vulnérabilités OWASP Top 10 web (XSS, SQLi, XXE, etc.).
• Souvent avec un user unique.

Il rate systématiquement :

• Les API mobiles (pas découvertes par un crawler web).
• Les BOLA (requiert deux utilisateurs comparatifs et un vrai test d'autorisation).
• Le rate limiting abuse.
• Les GraphQL specifics.
• Les logic abuse.

Un vrai API pentest nécessite compétences et outillage distincts : connaissance OpenAPI, Burp Suite avec plugins API, tests à 2+ users, analyse des schémas JSON, test GraphQL introspection.

6.3 Code review qui passe à côté

Les revues de code focus sur :

• Injection SQL.
• XSS potentiels.
• Authentification (login).

Passent souvent à côté de :

• Les autorisations oubliées sur chaque endpoint.
• Mass assignment via ORMs.
• Schémas qui renvoient trop de champs (profils complets au lieu de 3 fields).
• Endpoints debug/admin laissés actifs.

Mitigation : checklists de review orientées API, linting automatique (Spectral, Stoplight), tests de sécurité schema-based.

6.4 Scans de vulnérabilités génériques

Outils comme Nessus ou Qualys détectent CVE dans les composants. Ils ne testent pas la logique applicative. Une app avec dépendances parfaitement à jour peut être trivialement vulnérable à BOLA sans qu'aucun scan générique le détecte.

7. L'émergence des outils API security dédiés

Face à ces enjeux, une catégorie d'outils spécialisés est apparue depuis 2019.

7.1 Solutions commerciales leaders 2026

7.2 Fonctionnalités typiques

• API discovery automatique via sniffing trafic ou analyse IaC.
• Schema learning : apprentissage du comportement "normal".
• Anomaly detection ML sur patterns comportementaux.
• Policy enforcement runtime (rate limiting contextuel, blocage).
• Threat intel : détection d'IPs et patterns connus malveillants.
• API testing continu en CI/CD.
• Compliance reporting (PCI-DSS, HIPAA, GDPR).

7.3 Open source et DIY

Pour les équipes avec budget limité :

• Akto : discovery + testing.
• APIClarity : sniffer + OpenAPI spec generation.
• Spectral (Stoplight) : linting OpenAPI avec règles sécurité.
• OWASP ZAP + Postman : tests manuels + automatisés.
• Kong Gateway avec plugins sécurité : rate limiting, auth, logging.
• Envoy en sidecar avec filtres custom.

8. Le futur proche - IA, agents et API

8.1 LLM comme amplificateur d'attaque

Les attaquants utilisent déjà les LLMs pour :

• Générer automatiquement des requêtes d'exploration API à partir d'un schéma OpenAPI.
• Construire des payloads de fuzzing ciblés.
• Analyser en masse les réponses pour détecter des anomalies révélatrices.

8.2 Agents AI qui consomment des API

Les agents AI autonomes (MCP, tool-calling, agentic systems) appellent des API pour agir. Nouvelles problématiques :

• Prompt injection qui manipule l'agent pour appeler des endpoints dangereux.
• Excessive agency : agent avec trop de permissions API qui peut causer des dommages.
• API abuse non-humain à vitesse machine.
• Auth pour agents : pas human-in-the-loop, MFA impossible.

OWASP prépare un Top 10 pour agents AI qui référence explicitement les problématiques API spécifiques.

8.3 API-to-API abuse

Dans un écosystème microservices, une compromission d'un service peut mener à des appels abusifs vers d'autres services internes. Mitigation : mTLS obligatoire, service mesh, policies par service, zero trust inter-service.

9. Les conséquences pour tout ingénieur

9.1 Shift-left API security

• Design : threat model de chaque endpoint avant code.
• Development : linters sécurité orientés API (Spectral, 42Crunch scan).
• Testing : tests automatisés d'autorisation (BOLA, BFLA) avec 2+ users.
• CI : scan OpenAPI avant merge.
• Runtime : WAAP + API security platform.
• Monitoring : alertes comportementales API-aware.

9.2 Inventaire obligatoire

• Discovery automatique + manuel combiné.
• Versioning clair, désactivation des vieilles versions.
• Documentation OpenAPI à jour dans un registre central.
• Ownership par API, par endpoint.

9.3 Authentification et autorisation solides

• OAuth 2.0 + OIDC standard, pas de custom.
• mTLS pour les communications inter-services.
• Scopes fins par endpoint.
• Authorization centralisée via middleware ou OPA.
• Rate limiting par user et par endpoint avec seuils adaptés au métier.

9.4 Rate limiting intelligent

Pas un limit par IP uniforme : adaptatif.

• Limites par user, par endpoint, par ressource.
• Détection de patterns d'abus (scraping progressif, brute force lent).
• Réponse graduée : ralentir → challenge → bloquer.

9.5 Data minimization

• Ne renvoyer que les champs nécessaires (pas d'objet complet par défaut).
• Pagination stricte avec limites (pas de ?limit=1000000).
• Pas de données sensibles dans les réponses (pas de ssn, password_hash, raw_address sauf justifié).

10. Plan d'action - démarrer un programme API security

Semaines 1-4 - visibilité

• Inventaire manuel des API exposées.
• Déploiement d'un outil de discovery (Akto, Postman API Network, ou WAAP avec discovery).
• Identification des shadow APIs.
• Classification par criticité.

Mois 2-3 - quick wins

• Désactivation des API zombies (versions obsolètes).
• Ajout d'authentification sur endpoints "internes" exposés.
• Rate limiting basique sur tous les endpoints (défense en profondeur).
• Documentation OpenAPI à jour pour les API critiques.

Mois 4-6 - tests et enforcement

• Intégration de Spectral ou 42Crunch en CI pour linting.
• Tests automatisés BOLA/BFLA en CI (scripts avec 2 users).
• Mise en place WAAP moderne ou API security platform.
• Alertes SIEM pour événements API anormaux.

Mois 7-12 - maturité

• Pentest API dédié annuel (distinct du pentest web).
• Formation développeurs OWASP API Top 10.
• Métriques dashboard : shadow APIs détectées, BOLA coverage, latence enforcement.
• Préparation conformité (SOC 2, ISO 27001 API-specific controls).

11. Verdict et posture Zeroday

Les API ne sont pas un sujet parmi d'autres en 2026 : c'est la surface d'attaque dominante, et celle qui grandit le plus vite. Les défenses traditionnelles (WAF classique, pentest web générique) n'en couvrent qu'une fraction. Les équipes qui n'ont pas formalisé un programme API security dédié opèrent aveugles sur leur principal vecteur de risque applicatif.

Pour un ingénieur : la spécialisation API security est un axe de carrière en forte croissance et bien rémunéré. Profils rares sur le marché français, salaires compétitifs, demande croissante. Voir métier expert API security pour le détail.

Pour une organisation : démarrer petit (inventaire + rate limiting + désactivation zombies) produit déjà des gains sécuritaires significatifs pour un coût faible. La montée en maturité (plateforme dédiée, tests automatisés, governance) se fait sur 12-18 mois et se justifie économiquement par le coût moyen d'un breach API (entre 5 et 50 millions USD selon IBM Cost of a Data Breach 2024).

Pour approfondir : introduction à l'OWASP Top 10 pour le contexte général AppSec, broken access control pour le parent de BOLA/BFLA, c'est quoi une vulnérabilité SSRF pour le focus SSRF, gestion de session sécurisée pour la couche session qui sous-tend l'auth API, service accounts : risques et bonnes pratiques pour les identités machine qui consomment les API. Les articles ultérieurs de la catégorie API Security approfondiront chaque angle individuellement.