OWASP API Top 10 : les 10 failles d'API à connaître en 2026

Pourquoi un Top 10 spécifique aux API

Les API sont devenues le vecteur d'attaque principal des applications modernes. Contrairement aux applications web traditionnelles où l'interface contrôle les interactions, les API exposent directement la logique métier. L'OWASP a publié un Top 10 dédié aux API en 2019, mis à jour en 2023. Voici les dix catégories et ce qu'elles signifient concrètement.

API1 : Broken Object Level Authorization (BOLA)

L'équivalent API de l'IDOR. L'utilisateur A accède aux ressources de l'utilisateur B en changeant l'identifiant dans la requête. GET /api/orders/1234 devrait vérifier que l'appelant est bien propriétaire de la commande 1234. C'est la faille API numéro un parce que les développeurs oublient systématiquement ce contrôle.

API2 : Broken Authentication

Tokens sans expiration, absence de rate limiting sur les endpoints de login, clés API dans les URL, tokens JWT sans validation de signature. Tout mécanisme d'authentification mal implémenté entre dans cette catégorie.

API3 : Broken Object Property Level Authorization

L'API retourne plus de champs que nécessaire (email, role, internal_notes) ou accepte la modification de champs sensibles via mass assignment. Si PATCH /api/users/me accepte {"role": "admin"}, c'est une faille de cette catégorie.

API4 : Unrestricted Resource Consumption

Pas de pagination, pas de rate limiting, pas de limite sur la taille des payloads. Un attaquant peut extraire l'intégralité de la base via des requêtes paginées automatisées ou provoquer un déni de service en envoyant des payloads massifs.

API5 : Broken Function Level Authorization

Un utilisateur standard accède à des endpoints d'administration. DELETE /api/admin/users/42 est accessible sans vérification du rôle. La documentation Swagger expose souvent ces endpoints aux yeux de tous.

API6 : Unrestricted Access to Sensitive Business Flows

L'API ne protège pas les flux métier critiques contre l'automatisation. Achat massif automatisé, création de comptes en boucle, brute force de codes promotionnels. Ce n'est pas un bug technique mais un manque de contrôle métier.

API7 : Server-Side Request Forgery

Même principe que la SSRF web mais via les endpoints API. Les fonctions d'import, de webhook et d'intégration tierce sont les vecteurs principaux.

API8 : Security Misconfiguration

Headers CORS trop permissifs (Access-Control-Allow-Origin: * sur des endpoints authentifiés), verbose error messages exposant des stack traces, méthodes HTTP non nécessaires activées, documentation API accessible en production.

API9 : Improper Inventory Management

APIs non documentées, anciennes versions encore accessibles, environnements de staging exposés sur Internet. Si /api/v1/ est sécurisé mais que /api/v0/ est encore en ligne sans authentification, c'est cette catégorie.

API10 : Unsafe Consumption of APIs

Votre API fait confiance aveuglément aux données reçues des API tierces. Si un fournisseur est compromis ou renvoie des données malveillantes, votre application les traite sans validation. C'est un vecteur de supply chain côté API.

L'approche CleanIssue

Notre revue externe teste chacune de ces dix catégories sur vos endpoints exposés. Les failles BOLA et Broken Authentication représentent à elles seules plus de 50% de nos findings critiques. Demandez un revue externe pour identifier vos failles API.