1. Broken Object Level Authorization (BOLA / IDOR)
Le vecteur OWASP API Security #1. Un utilisateur authentifié peut accéder aux ressources d’un autre utilisateur simplement en manipulant un identifiant dans l’URL. Exemple d’exploitation :GET /api/invoices/12457 → facture d’un autre client accessible sans contrôle d’appartenanceContre-mesures à la Gateway :
- Implémenter un middleware d’authorization context qui enrichit chaque requête avec les claims de l’utilisateur authentifié
- Valider systématiquement que l’identifiant de ressource appartient au tenant de la requête
- Logger toutes les tentatives d’accès à des ressources hors scope pour détection d’anomalies
- Utiliser des UUIDs opaques plutôt que des IDs séquentiels – réduction de la surface d’énumération
2. Broken Authentication & Token Management
Les implémentations JWT défectueuses restent parmi les vulnérabilités les plus exploitées. Cas fréquents rencontrés en audit :- Algorithme « none » accepté par le serveur (CVE classique, toujours présent en 2024)
- Secret JWT faible ou hardcodé dans le codebase
- Tokens sans expiration ou avec TTL excessif (> 24h pour des tokens d’accès)
- Absence de mécanisme de révocation – un token volé reste valide jusqu’à expiration
- Refresh tokens stockés en localStorage (XSS accessible) au lieu de httpOnly cookies
- Access token : TTL court (15 à 60 min), signé RS256 (asymétrique)
- Refresh token : TTL long (7-30 jours), rotation à chaque usage, stocké httpOnly
- Blacklist Redis pour la révocation immédiate en cas de compromission
- Validation de la signature côté Gateway avant tout forwarding vers les backends
3. Excessive Data Exposure
Les APIs retournent systématiquement plus de données que nécessaire, laissant au client le soin de filtrer. Ce pattern expose des données sensibles même quand l’interface n’en affiche qu’une partie. Pattern anti-sécurité observé :GET /api/users/me → retourne l’objet User complet incluant hash du mot de passe, token de reset, données bancaires partiellesContre-mesures :
- Response filtering au niveau Gateway : whitelist des champs autorisés par endpoint et par rôle
- Implémenter des Data Transfer Objects (DTO) distincts par use case côté backend
- Audit régulier des réponses API via fuzzing automatisé (OWASP ZAP, Burp Suite)
- GraphQL : implémenter query depth limiting et field-level permissions
4. Lack of Resources & Rate Limiting
L’absence de rate limiting expose vos APIs à deux catégories de risques : les attaques par déni de service et le credential stuffing (brute force distribué sur des endpoints d’authentification). Stratégie de rate limiting par couches :-
Layer 1 – IP-based : 1000 req/min par IP globale, 10 req/min sur /auth/login
-
Layer 2 – User-based : 500 req/min par user_id authentifié
-
Layer 3 – Tenant-based : quotas différenciés par plan (Free / Pro / Enterprise)
-
Layer 4 – Endpoint-based : limites spécifiques sur les endpoints coûteux (export, génération de rapport)
- Algorithme Token Bucket pour les limites globales (lissage du trafic)
- Algorithme Sliding Window pour les limites d’authentification (précision sur les pics courts)
- Headers de réponse standardisés : X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After
- Stockage des compteurs en Redis (TTL natif, performance sub-milliseconde)
5. Function Level Authorization (Broken Access Control)
Distincte du BOLA, cette vulnérabilité concerne les actions (verbes) plutôt que les ressources. Un utilisateur avec un rôle limité peut accéder à des endpoints d’administration non protégés. Pattern fréquemment observé :- Endpoints /admin/* non protégés car « on suppose que l’interface ne les expose pas »
- Vérification des rôles uniquement côté frontend (security by obscurity)
- Permissions vérifiées uniquement au niveau applicatif mais pas à la Gateway
- Définir une matrice de permissions explicite (RBAC ou ABAC) par endpoint
- Implémenter la vérification de permissions à la Gateway via OPA (Open Policy Agent)
- Adopter le principe du moindre privilège : tout ce qui n’est pas explicitement autorisé est refusé
- Tester systématiquement les endpoints avec des tokens de rôles inférieurs (tests d’autorisation automatisés)
6. Mass Assignment
Cette vulnérabilité survient quand une API accepte des propriétés d’objet non prévues dans le payload de requête, permettant à un attaquant de modifier des champs sensibles (is_admin, role, balance). Exemple d’exploitation :PATCH /api/profile avec payload { « name »: « John », « role »: « admin » } – si le backend bind l’objet complet sans whitelistContre-mesures :
- Validation stricte des payloads à la Gateway via JSON Schema (whitelist des champs acceptés)
- Ne jamais binder directement le corps de requête sur un modèle de données
- Utiliser des DTOs d’input distincts avec validation explicite de chaque champ
- Tester avec des payloads enrichis lors des revues de sécurité
7. Security Misconfiguration
La catégorie fourre-tout qui regroupe les oublis de configuration les plus coûteux :- CORS trop permissif : Access-Control-Allow-Origin: * en production
- Headers de sécurité manquants : X-Content-Type-Options, X-Frame-Options, HSTS non configuré
- Endpoints de debug ou Swagger UI exposés en production
- Stack traces et messages d’erreur verbeux retournés aux clients
- TLS 1.0/1.1 encore acceptés, suites cryptographiques faibles
- Secrets de configuration dans les variables d’environnement accessibles via metadata API (cas AWS EC2)
- CORS : whitelist explicite des origines autorisées
- Security headers : implémenter via la Gateway pour couvrir tous les backends
- Supprimer tous les endpoints /debug, /health (ou les restreindre aux IPs internes)
- Error handling uniforme : retourner des erreurs standardisées sans information interne
- TLS 1.2 minimum, TLS 1.3 recommandé, HSTS preload activé
8. Injection (SQL, NoSQL, Command)
Les injections restent dans le top 3 des vulnérabilités malgré des décennies de sensibilisation. Dans le contexte API, elles prennent des formes moins visibles que les formulaires web classiques :- Injection via query parameters : GET /api/products?filter=’; DROP TABLE products; —
- Injection NoSQL via payload JSON : { « $where »: « this.password == ‘x’ || ‘x’ == ‘x' » }
- Template injection dans des endpoints de génération de documents ou d’emails
- WAF (Web Application Firewall) à la Gateway : AWS WAF, Cloudflare WAF, ModSecurity
- Validation et sanitisation strictes de tous les inputs (requête, headers, query params)
- Requêtes paramétrées obligatoires côté backend – aucune concaténation de strings SQL
- Principe du moindre privilège sur les comptes de base de données
9. Improper Assets Management
Ce dernier vecteur est souvent le plus dangereux en production : des versions obsolètes d’API restent accessibles, avec des vulnérabilités corrigées dans les versions récentes mais toujours présentes dans les anciennes.- /api/v1/* non décommissionné alors que /api/v3/* est en production
- Environnements de staging accessibles avec des données de production
- Endpoints de test ou de migration laissés actifs après la mise en production
- Maintenir un inventaire exhaustif de toutes les APIs exposées (API Registry)
- Politique de dépréciation formelle : minimum 6 mois de période de migration entre versions
- Monitoring des appels sur les versions dépréciées pour identifier les clients restants
- Tests de sécurité automatisés intégrés au pipeline CI/CD – les vulnérabilités connues ne doivent pas passer en production
