API exposées : comment les détecter et les sécuriser
Les API sont partout. Elles relient vos applications mobiles, vos intégrations partenaires, vos microservices, vos outils SaaS. Selon Salt Security, 94% des organisations ont connu des problèmes de sécurité API en 2024. Et pourtant, la plupart des organisations n'ont pas d'inventaire complet de leurs API exposées.
Pourquoi les API sont-elles si vulnérables ?
La proliferation des API
Une ETI typique expose entre 500 et 5 000 API. Chaque service SaaS, chaque intégration, chaque microservice ajoute de nouvelles API. La plupart ne sont pas documentées.
Les API zombies
Les API zombies (ou shadow APIs) sont des endpoints qui ne sont plus maintenus mais restent actifs. Ils contiennent souvent des vulnérabilités non parchées et des authentifications faibles.
L'authentification insuffisante
OWASP API Security Top 10 classe les problèmes d'authentification (Broken Object Level Authorization) comme la vulnérabilité #1 des API.
OWASP API Security Top 10 2023
| Rang | Vulnérabilité | Description |
|---|---|---|
| #1 | Broken Object Level Authorization | Accès à des objets sans autorisation |
| #2 | Broken Authentication | Authentification faible ou absente |
| #3 | Broken Object Property Level Auth | Exposition de propriétés sensibles |
| #4 | Unrestricted Resource Consumption | Pas de rate limiting |
| #5 | Broken Function Level Authorization | Accès à des fonctions administratives |
| #6 | Unrestricted Access to Sensitive Business Flows | Abus des flux métier |
| #7 | Server Side Request Forgery | SSRF via paramètres API |
| #8 | Security Misconfiguration | Configurations par défaut, CORS ouvert |
| #9 | Improper Inventory Management | API non documentées, versions obsolètes |
| #10 | Unsafe Consumption of APIs | Confiance aveugle dans les réponses API |
Comment détecter vos API exposées ?
Méthode 1 : Détection passive via l'EASM
L'EASM identifie les API en analysant :
- Les endpoints JSON/REST sur vos domaines et sous-domaines
- Les fichiers de documentation exposés (swagger.json, openapi.yaml, api-docs)
- Les réponses HTTP contenant des Content-Type API (application/json, application/xml)
- Les ports standards des frameworks API (3000, 8080, 8443, 4000)
Méthode 2 : Analyse des certificats et DNS
Les sous-domaines contenant api., api-, -api, gateway, ws. sont des indicateurs forts d'une API.
Méthode 3 : Google Dorks
site:company.com filetype:json
site:company.com "swagger"
site:company.com "api_key"
Les configurations API à risque détectées par l'EASM
| Configuration | Risque | Rémédiation |
|---|---|---|
CORS ouvert (Access-Control-Allow-Origin: *) | Vuln. CORS, accès depuis n'importe quelle origine | Restreindre aux origines autorisées |
| Documentation Swagger public | Cartographie complète pour l'attaquant | Protéger l'accès, authentification requise |
| Pas de rate limiting | Brute force, DoS | Implémenter rate limiting + captcha |
| API v1 toujours active | Version obsolète vulnérable | Désactiver les anciennes versions |
| Pas d'authentification | Accès libre aux données | API keys minimum, OAuth recommandé |
| HTTPS non forcé | Interception du trafic | Forcer TLS 1.2+ sur tous les endpoints |
Plan de sécurisation des API en 5 étapes
Étape 1 : Inventaire Construire un registre complet de toutes les API exposées (endpoint, version, méthodes d'authentification, données traitées, propriétaire).
Étape 2 : Classification Classifier chaque API par niveau de risque : publique/privée, données sensibles/non sensibles, critique/standard.
Étape 3 : Authentification et autorisation Implémenter OAuth 2.0 / JWT pour toutes les API. Vérifier l'autorisation au niveau objet (BOLA).
Étape 4 : Sécurisation technique Rate limiting, validation des entrées, HTTPS forcé, headers de sécurité, CORS restrictif.
Étape 5 : Surveillance continue Monitoring des anomalies de trafic, alertes sur les nouveaux endpoints exposés, revue régulière de l'inventaire.