Pentest d'API REST : méthode OWASP API Top 10 et rapport

• API1 - BOLA (Broken Object Level Authorization) : l'API expose des objets (commandes, factures, profils) en utilisant l'ID de l'objet dans l'URL. L'attaquant change l'ID pour accéder aux données d'autres utilisateurs. Exemple : GET /api/orders/12345 → changer pour /api/orders/12344
• API2 - Broken Authentication : mécanismes d'authentification défaillants (JWT sans vérification de signature, tokens sans expiration, reset password brute-forceable)
• API3 - Broken Object Property Level Authorization : accès à des propriétés d'objet non autorisées (mass assignment, surexposition de champs sensibles)
• API4 - Unrestricted Resource Consumption : absence de rate limiting permettant les attaques DoS, le scraping massif, ou la consommation excessive de ressources
• API5 - Broken Function Level Authorization : accès à des fonctions administratives via des endpoints non protégés (DELETE, PUT sur des ressources critiques)
• API6 - Unrestricted Access to Sensitive Business Flows : flux métier exploitables (achats massifs, création en masse de comptes, manipulation de workflows)
• API7 - Server Side Request Forgery (SSRF) : l'API effectue des requêtes HTTP vers des URLs contrôlées par l'attaquant, permettant l'accès aux métadonnées cloud ou aux services internes
• API8 - Security Misconfiguration : en-têtes de sécurité manquants, CORS trop permissif, méthodes HTTP non nécessaires exposées, messages d'erreur verbeux
• API9 - Improper Inventory Management : versions API obsolètes non supprimées, endpoints de debug en production, shadow APIs non documentées
• API10 - Unsafe Consumption of APIs : consommation d'APIs tierces sans validation des réponses, injection via API externe compromise

Avant de tester les vulnérabilités, il faut cartographier l'API :

Sources d'information

• Documentation officielle : Swagger/OpenAPI (swagger.json, openapi.yaml), Postman collections partagées, documentation développeur
• JavaScript source : les SPA exposent souvent leurs endpoints API dans le code JS (bundle.js). Utiliser LinkFinder ou JSParser
• Trafic réseau : capturer le trafic de l'application mobile ou web en proxy (Burp Suite, mitmproxy) pour découvrir les endpoints appelés
• Google Dork : rechercher les endpoints exposés publiquement (site:target.com inurl:api, site:target.com filetype:json)
• Fuzzing de répertoires : FFUF avec une wordlist API (/api/v1, /api/v2, /graphql, /admin, /health) pour découvrir les endpoints non documentés

• Burp Suite Pro : proxy interceptant les requêtes API, scanner d'injection automatique, replay et modification de requêtes. Indispensable pour le pentest API.
• Postman : client API permettant d'importer une collection OpenAPI, de paramétrer des tests, de scripter des scénarios d'attaque (pre-request scripts, tests en JavaScript)
• FFUF : fuzzer web ultrarapide pour l'énumération des endpoints, paramètres cachés (FUZZ dans l'URL/body), et le brute force de valeurs numériques d'ID (BOLA)
• Nuclei : templates de tests pour les vulnérabilités API courantes (JWT misconfiguration, exposed Swagger, debug endpoints). Très efficace pour les tests automatisés.
• jwt_tool : outil spécialisé pour tester les vulnérabilités JWT (alg:none, RS256/HS256 confusion, key confusion, brute force du secret)
• Arjun : découverte de paramètres HTTP cachés dans les endpoints GET et POST
• Kiterunner : alternative à FFUF spécialisée API, avec des wordlists issues de vraies API (OpenAPI specs)

Tester le BOLA (API1)

Le BOLA est la vulnérabilité API la plus répandue et souvent la plus impactante. Méthode de test :

• Créer deux comptes utilisateurs (utilisateur A et utilisateur B)
• Avec l'utilisateur A, créer une ressource (commande, profil, document)
• Capturer l'ID de la ressource dans l'URL ou la réponse
• Avec le token de l'utilisateur B, tenter d'accéder à la ressource de A via GET, PUT, DELETE
• Si l'accès est accordé → BOLA confirmé

Tester les JWT (API2)

• Alg:none : modifier le header JWT `"alg":"none"` et supprimer la signature — certaines implémentations acceptent les JWT non signés
• RS256 → HS256 confusion : si le serveur accepte HS256, utiliser la clé publique RSA comme secret HMAC
• Brute force du secret : jwt_tool avec hashcat pour cracker les JWT signés HS256 avec des secrets courts
• Expiration : vérifier si les tokens expirés sont toujours acceptés après déconnexion

Un rapport de pentest API doit être exploitable par les développeurs et compréhensible par la direction. Structure recommandée :

• Résumé exécutif : niveau de risque global, nombre de vulnérabilités par sévérité, impact métier en langage non technique
• Méthodologie : périmètre du test (endpoints inclus/exclus), méthode (boîte blanche/grise/noire), outils utilisés, dates
• Vulnérabilités détaillées : pour chaque finding : titre, sévérité CVSS, description, endpoint affecté, étapes de reproduction, capture d'écran, impact, recommandations de remédiation
• Plan de remédiation priorisé : liste des correctifs par ordre de criticité avec estimation de complexité de correction
• Annexes techniques : requêtes/réponses brutes, payloads utilisés, logs d'outils automatisés

• Autorisation côté serveur : vérifier à chaque requête que l'utilisateur authentifié a le droit d'accéder à la ressource demandée (solution BOLA)
• Rate limiting : limiter le nombre de requêtes par IP, par utilisateur et par endpoint avec des règles différenciées
• Suppression des endpoints obsolètes : désactiver les anciennes versions d'API (/api/v1 quand /api/v3 est en production)
• Validation des entrées : valider et assainir tous les paramètres de requête, body et headers
• En-têtes de sécurité : X-Content-Type-Options, CORS restrictif, Content-Security-Policy, Strict-Transport-Security
• API Gateway : centraliser l'authentification, le rate limiting et les logs via une API Gateway (AWS API GW, Kong, Apigee)