Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Pen Test API

devsecops

Définition

Le Penetration Testing API (pentest d'API) est une évaluation de sécurité offensive spécifiquement dédiée aux interfaces de programmation applicative (APIs REST, GraphQL, WebSocket, gRPC), cherchant à identifier et exploiter les vulnérabilités de sécurité dans ces APIs. Les APIs sont devenues la surface d'attaque principale des applications modernes (Gartner estimait en 2022 que les APIs allaient devenir la principale surface d'attaque), justifiant une approche de pentest spécialisée distincte du pentest web classique. Un pentest API suit méthodologiquement les 10 risques de l'OWASP API Security Top 10 : BOLA/IDOR (accès à des objets appartenant à d'autres utilisateurs), authentification cassée, exposition de propriétés, consommation non restreinte de ressources, authorization au niveau des fonctions, SSRF, misconfigurations de sécurité, logging insuffisant, inventory management défaillant, et consommation non sécurisée d'APIs tierces. Chaque risque est testé méthodiquement sur l'API cible. Les phases d'un pentest API incluent : la reconnaissance (découverte de la surface d'API via la documentation OpenAPI/Swagger, les applications frontend, les applications mobiles décompilées, et les techniques de discovery actif comme le fuzzing des chemins), l'authentification testing (tests des mécanismes d'authentification, tentatives de brute force, tests de tokens JWT mal configurés), les tests d'autorisation (BOLA — accès aux ressources d'autres utilisateurs, BFLA — accès à des fonctions non autorisées), les tests d'injection (SQL, NoSQL, XSS via les paramètres d'API), et les tests de logique métier (séquences de requêtes inattendues, manipulation des paramètres pour accéder à des fonctionnalités non prévues). Les outils de pentest API incluent : Burp Suite Professional (proxy d'interception, scanner actif, extensions API-specific), Postman avec des collections de tests de sécurité, OWASP ZAP avec l'extension API Scanner, 42Crunch API Security Audit, InQL (Burp extension pour GraphQL), et des frameworks de test CLI comme http pie, httpie, et curl pour les tests manuels précis.

Reconnaissance et cartographie des APIs

La reconnaissance est la phase la plus importante d'un pentest API : l'objectif est de cartographier toute la surface d'API disponible. Sources : documentation OpenAPI/Swagger officielle (si accessible), capture du trafic de l'application web frontend ou mobile (via le proxy Burp/ZAP), décompilation des applications Android (apktool, jadx — pour trouver les endpoints hardcodés), analyse du JavaScript frontend (souvent riche en endpoints API), et tentatives de discovery actif (fuzzing des chemins avec SecLists/api-endpoints, enumération des anciens endpoints via Wayback Machine). La cartographie complète identifie souvent des endpoints non documentés (Shadow APIs).

Tests BOLA : accès aux ressources d'autres utilisateurs

Le test BOLA (Broken Object Level Authorization) est systématique dans tout pentest API : créer deux comptes (UserA et UserB), créer des ressources avec UserA (commandes, profils, documents), puis accéder à ces ressources avec l'ID de UserA depuis UserB (GET /api/orders/12345 avec le token d'authentification de UserB). Si la réponse est 200 avec les données de UserA, la BOLA est confirmée. Ce test simple découvre l'une des vulnérabilités les plus répandues et les plus impactantes des APIs REST modernes. Des outils comme autorize (Burp extension) automatisent ce test pour tous les endpoints découverts.

Reporting d'un pentest API

Un rapport de pentest API efficace structure les findings par risque OWASP API Security Top 10 pour faciliter le triage : chaque finding inclut le titre (ex: BOLA sur /api/v1/orders/{id}), la sévérité CVSS, le vecteur d'exploitation démontré (screenshot ou capture du trafic avec le payload et la réponse confirmant la vulnérabilité), l'impact business (données exposées, actions non autorisées possibles), et la recommandation de remédiation avec exemple de code corrigé. La classification par risque OWASP permet à l'équipe DevSecOps de contextualiser les findings dans leur programme de sécurité API existant.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis