Les APIs sont devenues le cœur des applications modernes. Microservices, applications mobiles, intégrations SaaS : tout passe par des endpoints REST ou GraphQL. Cette surface d'attaque élargie a conduit l'OWASP à publier une liste dédiée aux risques spécifiques aux APIs.
Les 10 risques OWASP API Security
1. Broken Object Level Authorization (BOLA)
Le risque le plus courant. Une API expose des objets identifiés par un ID, et ne vérifie pas que l'utilisateur a le droit d'accéder à cet objet précis.
Exemple : GET /api/users/1234/invoices retourne les factures d'un autre utilisateur si vous changez l'ID.
Remédiation : Vérifier systématiquement que l'objet demandé appartient à l'utilisateur authentifié. Ne pas exposer les IDs séquentiels — préférer les UUIDs.
2. Broken Authentication
Mécanismes d'authentification mal implémentés : tokens JWT sans expiration, secrets faibles, absence de rate limiting sur les endpoints de login.
Remédiation : Tokens JWT avec expiration courte (15-60 min), refresh tokens stockés httpOnly, rate limiting sur /auth/*, MFA pour les comptes sensibles.
3. Broken Object Property Level Authorization
L'API expose des propriétés que l'utilisateur ne devrait pas voir (mass assignment) ou permet de modifier des champs protégés.
Exemple : PATCH /api/users/me accepte {"role": "admin"} sans validation.
Remédiation : Whitelister explicitement les propriétés acceptées. Utiliser des DTOs stricts avec validation Zod ou similaire.
4. Unrestricted Resource Consumption
Absence de limites sur la taille des requêtes, le nombre d'enregistrements retournés, ou les opérations coûteuses. Mène au DoS ou à des coûts cloud explosifs.
Remédiation : Pagination obligatoire, limites sur la taille des payloads, rate limiting par user et par IP, timeout sur les requêtes.
5. Broken Function Level Authorization
Des endpoints administratifs accessibles aux utilisateurs normaux. La sécurité par l'obscurité (cacher les routes admin) ne suffit pas.
Remédiation : Contrôle d'accès basé sur les rôles (RBAC) sur chaque endpoint. Tester les routes admin avec un token utilisateur standard.
6. Unrestricted Access to Sensitive Business Flows
Des flux métier critiques (achat, vote, inscription) exposés sans protection contre l'automatisation abusive.
Remédiation : CAPTCHA sur les flux sensibles, détection d'anomalies comportementales, rate limiting métier (ex: 3 achats/minute max).
7. Server Side Request Forgery (SSRF)
L'API accepte des URLs fournies par l'utilisateur et effectue des requêtes vers ces URLs depuis le serveur. Permet d'atteindre des services internes non exposés.
Remédiation : Valider et filtrer toutes les URLs acceptées. Utiliser une allowlist de domaines. Bloquer les plages IP privées (10.x.x.x, 172.16.x.x, 192.168.x.x).
8. Security Misconfiguration
CORS trop permissif (Access-Control-Allow-Origin: *), headers de sécurité manquants, messages d'erreur exposant la stack trace, endpoints de debug actifs en production.
Remédiation : Revue régulière de la configuration CORS, CSP, HSTS. Désactiver les endpoints de debug en production. WarDek détecte automatiquement ces misconfigurations.
9. Improper Inventory Management
Des versions d'API obsolètes exposées (v1, v2) avec des vulnérabilités connues, ou des environnements de staging accessibles publiquement.
Remédiation : Inventaire de toutes les versions API. Dépréciation formelle avec date de sunset. Isolation réseau des environnements non-production.
10. Unsafe Consumption of APIs
Votre application consomme des APIs tierces sans valider leurs réponses, en leur faisant confiance aveuglément. Une API compromise en amont compromet votre application.
Remédiation : Valider toutes les réponses d'APIs tierces avec des schémas stricts. Principe de moindre privilège sur les tokens d'accès. Monitoring des anomalies.
Matrice de risques par type d'application
Toutes les APIs ne sont pas exposées aux mêmes risques. Le tableau suivant aide à prioriser vos efforts de sécurisation :
| Type d'API | Risques prioritaires | Pourquoi | |-----------|---------------------|----------| | API publique (SaaS) | BOLA (#1), Resource Consumption (#4), Inventory (#9) | Exposition maximale, utilisateurs non contrôlés | | API mobile | Authentication (#2), BOLA (#1), SSRF (#7) | Tokens stockés côté client, réseau non fiable | | API interne (microservices) | Function Auth (#5), Misconfiguration (#8), SSRF (#7) | Confiance implicite entre services = danger | | API partenaire (B2B) | Unsafe Consumption (#10), Property Auth (#3) | Dépendance à la sécurité du partenaire |
Bonnes pratiques transversales
Au-delà des remédiations spécifiques à chaque risque, certaines pratiques réduisent votre surface d'attaque globale :
Authentification et autorisation : Utilisez un framework d'autorisation centralisé (CASL, Casbin, OPA) plutôt que des vérifications ad hoc dans chaque endpoint. Un contrôle oublié = une faille BOLA.
Logging et monitoring : Loguez toutes les tentatives d'accès refusées, les échecs d'authentification et les patterns de requêtes anormaux. Sans monitoring, une attaque en cours est invisible.
Versioning et dépréciation : Maintenez un registre de toutes vos versions d'API. Chaque version obsolète non supprimée est une porte d'entrée potentielle avec des vulnérabilités connues.
Tests automatisés : Intégrez des tests de sécurité dans votre pipeline CI/CD. Des outils comme OWASP ZAP, Nuclei ou Burp Suite Community peuvent détecter automatiquement les injections, les CORS permissifs et les headers manquants.
Comment détecter ces vulnérabilités ?
Un scanner de sécurité comme WarDek détecte automatiquement plusieurs de ces risques : CORS permissif (OWASP #8), absence de headers de sécurité, exposition de stack traces, et endpoints sensibles. Pour une couverture complète, combinez l'analyse automatisée avec des tests manuels de pénétration.
Lancez un scan gratuit sur votre domaine pour identifier vos expositions critiques.