Les API sont devenues le tissu conjonctif du web moderne. Elles connectent vos applications mobiles, votre site web, vos partenaires et vos microservices. Mais elles sont aussi devenues la cible n°1 des attaquants : selon Gartner, les API seront le vecteur d’attaque le plus exploité d’ici 2025, et Salt Security rapporte une augmentation de 400% des attaques API entre 2022 et 2024.
Ce guide passe en revue les 10 failles du OWASP API Security Top 10 (2023) avec des exemples concrets et des corrections applicables.
Le OWASP API Security Top 10 (2023)
API1 – Broken Object Level Authorization (BOLA)
Le problème : un utilisateur accède aux données d’un autre en modifiant simplement l’ID dans l’URL (/api/users/123 devient /api/users/456).
La correction : vérifiez systématiquement que l’utilisateur authentifié a le droit d’accéder à l’objet demandé. Utilisez des UUID au lieu d’ID séquentiels pour limiter l’énumération.
API2 – Broken Authentication
Le problème : mécanismes d’authentification faibles – tokens sans expiration, pas de rate limiting sur le login, JWT mal validés.
La correction : implémentez OAuth 2.0 avec des tokens à durée de vie courte, activez le rate limiting, validez la signature ET les claims des JWT côté serveur.
API3 – Broken Object Property Level Authorization
Le problème : l’API retourne trop de données (mass assignment). Un utilisateur peut modifier des champs qu’il ne devrait pas (ex: "role": "admin" dans un PUT /profile).
La correction : utilisez des DTO (Data Transfer Objects) pour contrôler précisément les champs en entrée et en sortie. Ne faites jamais de bind automatique de la requête vers le modèle.
API4 – Unrestricted Resource Consumption
Le problème : pas de limites sur les requêtes, la taille des uploads ou la pagination. Un attaquant peut provoquer un déni de service ou une facture cloud explosive.
La correction : rate limiting par IP et par utilisateur, pagination obligatoire, taille maximale des payloads, timeouts sur les requêtes.
API5 – Broken Function Level Authorization
Le problème : un utilisateur standard accède à des endpoints admin (/api/admin/users) simplement en devinant l’URL.
La correction : centralisez les contrôles d’accès dans un middleware. Appliquez le principe du moindre privilège. Testez les accès avec différents rôles.
API6 – Unrestricted Access to Sensitive Business Flows
Le problème : des flux métier sensibles (achat, réservation, création de compte) sont exploités en masse par des bots.
La correction : CAPTCHA, fingerprinting, détection de comportements anormaux, limites métier (ex: max 5 réservations par heure).
API7 – Server Side Request Forgery (SSRF)
Le problème : l’API accepte des URL en entrée et les récupère côté serveur, permettant à l’attaquant de scanner le réseau interne ou d’accéder aux métadonnées cloud (169.254.169.254).
La correction : validez et filtrez les URL en entrée avec une allowlist. Bloquez les plages IP privées et les adresses de métadonnées cloud. Désactivez les redirections HTTP.
API8 – Security Misconfiguration
Le problème : headers de sécurité manquants, CORS trop permissif (Access-Control-Allow-Origin: *), messages d’erreur verbeux, endpoints de debug exposés.
La correction : hardening systématique : CORS restrictif, headers de sécurité (HSTS, X-Content-Type-Options), messages d’erreur génériques en production, désactivation de Swagger/debug en prod.
API9 – Improper Inventory Management
Le problème : des anciennes versions de l’API restent accessibles (/api/v1/), des endpoints de test ou internes sont exposés en production sans documentation.
La correction : maintenez un inventaire à jour de toutes vos API. Décommissionnez les anciennes versions. Utilisez un API Gateway pour centraliser le contrôle.
API10 – Unsafe Consumption of APIs
Le problème : votre application fait confiance aveuglément aux données reçues d’API tierces sans validation.
La correction : validez et sanitisez toutes les données reçues d’API externes, exactement comme vous le feriez pour des entrées utilisateur. Utilisez HTTPS et vérifiez les certificats.
Checklist sécurité API
- Authentification OAuth 2.0 / OpenID Connect avec tokens courts
- Autorisation vérifiée à chaque requête (pas de confiance au client)
- Rate limiting et throttling par utilisateur et par IP
- Validation des entrées (schéma JSON, taille, type)
- Chiffrement TLS 1.2+ obligatoire
- Logs d’accès centralisés et surveillés
- Inventaire à jour de toutes les API exposées
- Tests de sécurité automatisés dans la CI/CD
- CORS configuré de manière restrictive
- Pas de données sensibles dans les URL (tokens, credentials)
Outils recommandés pour tester vos API
- Burp Suite : référence pour le test manuel d’API REST
- OWASP ZAP : alternative open source, bonne couverture automatisée
- Postman : tests fonctionnels et de sécurité basiques
- Nuclei : scanner de vulnérabilités avec templates API
- Semgrep : analyse statique du code pour détecter les failles en amont
FAQ
Par où commencer pour sécuriser nos API ?
Commencez par l’inventaire : listez toutes vos API exposées. Puis testez les failles BOLA (API1) et l’authentification (API2), qui représentent la majorité des compromissions réelles.
Faut-il un pentest spécifique pour les API ?
Oui. Un pentest web classique ne couvre pas les spécificités des API (logique métier, autorisation par objet, mass assignment). Demandez un pentest API dédié.
Besoin d’un audit de sécurité de vos API ? Contactez RM3A pour un pentest API sur-mesure.
