Méthodologie de pentest API 2026 : guide complet

Un pentest API est un audit ciblé des interfaces machine-to-machine d'une application (REST, GraphQL, gRPC, SOAP) qui suit une méthodologie distincte du pentest web classique. Les vulnérabilités dominantes sont structurelles : autorisations cassées au niveau objet (BOLA, API1:2023), fonction (BFLA, API5:2023) ou propriété (BOPLA, API3:2023), inventaire incomplet (shadow APIs, versions oubliées, environnements de staging exposés), authentification mal implémentée (JWT, OAuth 2.0, OIDC). La méthodologie 2026 s'articule autour de cinq phases — pré-engagement et cartographie, authentification et autorisation, business logic et rate limit, injections et exposition de données, GraphQL et architectures spécifiques — alignées sur le référentiel OWASP API Security Top 10 2023 et l'OWASP API Security Testing Guide. Cet article détaille chaque phase, les payloads typiques, l'outillage 2026 et les pièges fréquents.

Pourquoi une méthodologie API spécifique

Le pentest web traditionnel cible l'interface utilisateur. Le pentest API cible le contrat machine-to-machine sous-jacent. Trois différences structurelles imposent une méthodologie distincte.

Surface d'attaque plus large mais moins visible : une application web moderne expose typiquement 5 à 15 pages mais 50 à 500 endpoints API. La majorité des bugs critiques se trouvent sur les endpoints mal documentés ou oubliés (versions v1 et v2 cohabitent, endpoints de debug laissés en prod, environnements de staging accessibles).

Vulnérabilités d'autorisation dominantes : sur le web classique, XSS et CSRF dominent. Sur API, ce sont les contrôles d'autorisation au niveau objet (BOLA), fonction (BFLA) et propriété (BOPLA) qui représentent la majorité des bugs critiques. Selon le rapport Salt Security State of API Security 2024, plus de 60 % des incidents API analysés impliquent une faille d'autorisation.

Tests automatisés moins efficaces : un scanner web (DAST) crawle les liens et formulaires. Un scanner API a besoin du contrat (OpenAPI, GraphQL schema, Postman collection) pour comprendre la sémantique des paramètres et appliquer les bons payloads. Sans contrat, le scanner ne fait que du brute force d'endpoints, manquant 80 % de la surface réelle.

Phase 1 — Pré-engagement et cartographie

La phase la plus sous-estimée du pentest API. Sans une cartographie exhaustive, 30 à 50 % de la surface d'attaque réelle est manquée.

Documents à demander en pré-engagement

Lors du kick-off, demander explicitement :

• Spécification OpenAPI 3.x ou Swagger 2.0 (idéalement à jour, sinon la version la plus récente disponible).
• Schema GraphQL si l'API utilise GraphQL (introspection SDL ou fichier .graphql).
• Postman ou Insomnia collection utilisée par les développeurs internes.
• Comptes de test : au minimum 2 utilisateurs standards (rôles différents) + 1 admin si possible.
• Architecture : diagramme des services, gateways API utilisées (Kong, Apigee, AWS API Gateway, Azure APIM), identity provider (Auth0, Keycloak, Okta, Cognito).
• Périmètre exact : domaines, environnements (prod/staging), versions actives.

Cartographie active

Reconstruire ou compléter le contrat via interception et fuzzing.

# Interception du trafic legitimate via Burp Suite
# Configurer Burp comme proxy, utiliser les comptes de test sur le frontend
# Naviguer dans toutes les fonctionnalités pour capter les appels API
 
# Discovery active avec Kiterunner (wordlists API endpoints)
kr scan https://api.example.test \
   -w /opt/kiterunner/routes-large.kite \
   -o api-discovery.json
 
# Discovery passive avec Akto (déploiement Docker, ingestion de mirror traffic)
docker run -d -p 9090:9090 -p 9091:9091 \
   -e MONGO_URL=mongodb://mongo:27017/akto \
   aktosecurity/akto-api-runtime:latest
 
# Pour APIs mobiles : capture via mitmproxy + appareil iOS/Android
mitmproxy --mode reverse:https://api.example.test --listen-port 8080
 
# Énumération de versions oubliées
ffuf -u https://api.example.test/v1/FUZZ \
     -w /opt/wordlists/api-endpoints.txt \
     -mc 200,201,401,403
ffuf -u https://api.example.test/FUZZ/users \
     -w versions.txt -mc 200,201,401,403
# versions.txt = v0, v1, v2, v3, beta, alpha, dev, internal, legacy

Détection de shadow APIs

Les shadow APIs (endpoints non documentés, oubliés ou ajoutés sans gouvernance) représentent 30 à 40 % des découvertes critiques en pentest API. Sources de découverte :

• Subdomain enumeration : api-staging, api-dev, api-internal, api-old, api-test sur le domaine cible.
• Mobile app reverse : extraction de l'IPA/APK (apktool, jadx), recherche d'URLs hardcodées.
• JavaScript frontend analysis : LinkFinder, getJS, analyse des bundles webpack pour endpoints non publiés.
• Wayback Machine : gau ou waybackurls pour endpoints historiques.
• GitHub search : code GitHub interne ou public mentionnant des URLs internes.

Phase 2 — Authentification et autorisation

La majorité des findings critiques sortent de cette phase. Tester systématiquement chaque endpoint sous les angles d'authentification et de quatre niveaux d'autorisation.

Tests d'authentification

Tests BOLA (API1:2023)

Test central du pentest API. Pour chaque endpoint manipulant un objet identifié :

1. Créer deux comptes utilisateur (User A et User B).
2. Avec User A, créer une ressource (note, document, commande).
3. Avec User B, tenter d'accéder à cette ressource via son ID (GET, PATCH, DELETE).
4. L'accès doit être refusé (403). Si autorisé, c'est un BOLA confirmé.

L'extension Burp Autorize automatise ce test à grande échelle : elle rejoue chaque requête loggée comme User A avec le cookie de User B et compare les réponses.

Tests BFLA (API5:2023)

Vérifier que les fonctions admin ne sont pas accessibles aux utilisateurs standards :

# Avec un compte standard, tenter les endpoints admin
GET /api/admin/users HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGc...
 
# Si la réponse est 200 au lieu de 403, BFLA confirmé
# Tester aussi : POST/PUT/DELETE sur endpoints admin connus
# Tester avec : suppression du token, manipulation de claims JWT

Tests BOPLA (API3:2023)

Mass assignment et excessive data exposure. Deux variantes :

Mass assignment : envoyer dans le body des champs non documentés mais traités côté serveur.

# Création d'un compte utilisateur standard
POST /api/users HTTP/1.1
Content-Type: application/json
 
{
  "email": "test@example.test",
  "password": "Sup3rSecret!",
  "role": "admin",
  "isVerified": true,
  "credits": 999999
}
 
# Si le serveur traite role/isVerified/credits, BOPLA mass assignment

Excessive data exposure : la réponse retourne plus de champs que nécessaire.

GET /api/users/me HTTP/1.1
 
# Réponse problématique
{
  "id": 42,
  "email": "test@example.test",
  "passwordHash": "$2b$12$...",
  "ssn": "123456789",
  "internalNotes": "VIP customer",
  "stripeCustomerId": "cus_..."
}
# Champs sensibles renvoyés alors que le frontend n'en utilise que id et email

Phase 3 — Business logic et rate limit

Les vulnérabilités de logique métier sont rarement détectables par scanner. Elles demandent de comprendre la fonction de l'API et d'imaginer les abus possibles.

Tests de rate limit (API4:2023, API6:2023)

Rate limit absent ou contournable est une faille systémique en 2026. Tester :

Tests de contournement de rate limit : manipulation des headers (X-Forwarded-For, X-Real-IP, X-Originating-IP), rotation de tokens, batch requests GraphQL, race conditions.

Tests de race conditions

Deux requêtes concurrentes peuvent contourner des contrôles séquentiels (paiement double, multi-redemption de code promo, dépassement de quota).

L'extension Turbo Intruder de PortSwigger permet de tirer 30 à 100 requêtes en moins de 100 ms via single-packet attack (HTTP/2 multiplexing) :

# turbo-intruder script Python (PortSwigger Turbo Intruder)
def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           requestsPerConnection=100,
                           pipeline=False)
    for i in range(30):
        engine.queue(target.req)
 
def handleResponse(req, interesting):
    table.add(req)

Tests de mass actions et abus de fonctions business

Identifier les flows business sensibles (réservation, achat, transfert d'argent, vote, cumul de points) et tester les abus :

• Annuler après confirmation pour rembourser tout en gardant le bénéfice.
• Créer une ressource, la modifier juste avant validation pour passer outre des contrôles.
• Utiliser un endpoint legitimate de manière inhabituelle (export massif via une API conçue pour 1 à 5 enregistrements).

Phase 4 — Injections et SSRF

Les classes d'injection restent présentes en API mais avec des spécificités.

Injections SQL et NoSQL

Les ORM modernes (Prisma, TypeORM, Sequelize, SQLAlchemy, Hibernate) protègent contre l'injection paramétrée. Les vulnérabilités résiduelles se trouvent dans :

• Requêtes raw avec concaténation manuelle.
• Tri dynamique avec orderBy contrôlé par l'utilisateur (souvent non paramétré).
• Filtres avancés exposant le langage de requête (Elasticsearch DSL injection, MongoDB find).

SSRF (API7:2023)

L'API consomme une URL fournie par l'utilisateur (webhook, import, OEmbed, génération de PDF, preview de lien). Tests systématiques :

POST /api/webhooks/test HTTP/1.1
Content-Type: application/json
 
{ "target_url": "http://169.254.169.254/latest/meta-data/" }
{ "target_url": "http://localhost:6379/" }
{ "target_url": "http://internal.example.test:8080/admin" }
{ "target_url": "file:///etc/passwd" }
{ "target_url": "gopher://localhost:6379/_INFO" }
 
# Tests de bypass DNS rebinding, redirections suivies, IPv6

Injection de commandes

Toujours tester sur les endpoints qui semblent appeler des outils système (génération de PDF, export image, traitement vidéo, validation de fichier).

Phase 5 — GraphQL et architectures spécifiques

GraphQL ajoute une surface d'attaque distincte, souvent mal couverte par les outils REST classiques.

Tests GraphQL critiques

# Exemple de batch query pour brute force MFA contournant le rate limit
query AttemptOTP {
  a1: validateOTP(code: "000000") { success }
  a2: validateOTP(code: "000001") { success }
  a3: validateOTP(code: "000002") { success }
  # ... 100 codes en une seule requête HTTP
}

Architectures REST spécifiques

• gRPC : interception via grpc-web ou en clair sur HTTP/2. Outils : grpcurl, ghz pour tests, Burp avec plugin gRPC.
• WebSocket : tester l'authentification au handshake, valider les messages côté serveur, tester l'envoi de messages malformés.
• SOAP/XML : injection XXE (XML External Entity), XML signature wrapping, SAML attacks si SOAP+SAML.

OWASP API Security Top 10 2023 — référence rapide

Le référentiel pivot mis à jour en 2023. Tous les tests précédents s'alignent sur ces 10 classes.

Outillage 2026

Stack standard d'un pentester API confirmé en 2026.

Proxy d'interception

• Burp Suite Pro (license 449 $/an) avec extensions essentielles : Autorize, Param Miner, JWT Editor, Turbo Intruder, InQL pour GraphQL, Logger++, Active Scan++.
• Caido Pro : alternative moderne en Rust, interface web, performances supérieures sur grandes captures.
• mitmproxy : pour interception mobile et tests CLI scriptés.

API discovery et inventory

• Kiterunner (Assetnote) : discovery d'endpoints via wordlists optimisées API (routes-large.kite, routes-small.kite).
• Akto : open source, discovery passive via mirror traffic ou eBPF, inventory automatique.
• APIClarity : open source CNCF sandbox, capture eBPF + reconstruction OpenAPI.
• gau / waybackurls : énumération d'endpoints historiques.

Test automatisé schema-aware

• Schemathesis : property-based testing à partir d'OpenAPI ou GraphQL, génère des cas adversariaux.
• Nuclei templates API : règles publiques pour CVE et misconfig API courants.
• 42Crunch : commercial, scoring continu sur OpenAPI spec.

GraphQL spécifique

• InQL : extension Burp pour audit GraphQL.
• graphql-cop : tests automatisés des défauts GraphQL classiques.
• Altair / Insomnia GraphQL client : exploration interactive du schema.
• GraphQL Voyager : visualisation graphique du schema pour identifier surfaces sensibles.

Reporting spécifique API

Le rapport de pentest API ajoute deux éléments par rapport au rapport web classique :

1. Cartographie de l'API : diagramme ou tableau des endpoints découverts, classés par criticité, avec mention des shadow APIs trouvées hors documentation officielle.
2. Mapping OWASP API Top 10 : chaque finding référencé par son code OWASP API (API1 à API10) en plus du CWE et CVSS, pour faciliter la gouvernance sécurité côté commanditaire.

Les fiches de vulnérabilités API doivent inclure les requêtes HTTP brutes (avec headers complets, body, réponse), pas seulement des captures d'écran. Les équipes dev doivent pouvoir rejouer les requêtes en local pour reproduire et valider la remédiation.

Points clés à retenir

• Le pentest API est structurellement distinct du pentest web : surface plus large mais moins visible, vulnérabilités d'autorisation dominantes, scanners moins efficaces sans contrat.
• Les trois classes BOLA (API1), BOPLA (API3) et BFLA (API5) génèrent la majorité des findings critiques. Concentrer l'effort méthodologique sur ces classes.
• La cartographie initiale (OpenAPI demandé en pré-engagement, Kiterunner, mobile reverse, JS frontend analysis) conditionne 30 à 50 % du résultat final. Sans inventory, on rate les shadow APIs.
• GraphQL ajoute une surface d'attaque spécifique : introspection, batching, aliasing, query depth. Outils dédiés (InQL, graphql-cop) requis.
• Le rapport API doit inclure cartographie + mapping OWASP API Top 10, avec requêtes HTTP brutes pour permettre la reproduction par les équipes dev.

Pour aller plus loin

• Qu'est-ce qu'un pentest - définition générale, méthodologie PTES et cadre légal en France.
• Roadmap pentest web - parcours d'apprentissage carrière incluant un palier API moderne.
• Roadmap bug bounty - APIs en bug bounty, IDOR/BOLA comme classes les plus rentables.
• TJM pentester freelance - tarification d'une mission API en France 2026.