Pentest API : objectifs, méthodologie et exemples d’exploitation en boite noire, grise et blanche

Les API occupent aujourd’hui une place centrale dans les architectures applicatives. Applications web et mobiles, plateformes SaaS, infrastructures cloud, microservices, systèmes de paiement, logiciels métiers et intégrations avec des partenaires s’appuient sur des API pour échanger des données et déclencher des traitements parfois critiques.

Cette position centrale en fait également une surface d’attaque particulièrement intéressante. Une API peut exposer directement des données sensibles, des fonctions métier importantes ou des mécanismes permettant d’interagir avec d’autres composants du système d’information. Une faiblesse de contrôle d’accès peut permettre de consulter les données d’un autre utilisateur ou d’une autre organisation. Une erreur dans un workflow métier peut conduire à détourner un paiement, à réutiliser une opération qui ne devrait être exécutée qu’une seule fois ou à automatiser une fonctionnalité sensible à grande échelle. Une intégration backend mal sécurisée peut enfin transformer l’API en point d’accès vers des systèmes internes.

Les vulnérabilités affectant les API ne se limitent donc pas aux injections SQL, aux erreurs de configuration ou aux faiblesses techniques traditionnelles. Elles concernent aussi l’authentification, les modèles d’autorisation, les propriétés des objets, les mécanismes de limitation, la logique métier, la gestion des tokens, les interactions avec des services tiers et la maîtrise de l’inventaire des API exposées.

C’est précisément l’objectif d’un pentest API : confronter les mécanismes de sécurité de l’API à des scénarios d’attaque réalistes afin d’identifier les vulnérabilités réellement exploitables, de comprendre les conditions nécessaires à leur exploitation et d’en mesurer les conséquences techniques et métier.

Dans cet article, nous détaillons la méthodologie d’un pentest API, les principaux tests réalisés et les vulnérabilités les plus courantes. Nous revenons également sur l’OWASP API Security Top 10 2023, les particularités de REST, GraphQL, SOAP et gRPC, les mécanismes JWT, OAuth 2.0 et OpenID Connect ainsi que les différences entre pentests black box, grey box et white box.

Guide complet sur le pentest API

Qu’est-ce qu’un pentest API ?

Un pentest API consiste à évaluer la sécurité d’une interface de programmation en simulant les techniques qu’un attaquant pourrait utiliser pour accéder à des ressources auxquelles il ne devrait pas avoir accès, contourner les mécanismes d’authentification ou d’autorisation, manipuler les traitements réalisés par l’application ou compromettre les systèmes auxquels l’API est connectée.

Le pentest ne consiste donc pas simplement à envoyer une collection de payloads connus sur l’ensemble des paramètres disponibles. Le pentester cherche avant tout à comprendre le fonctionnement de l’API : quelles ressources elle expose, quels utilisateurs peuvent réaliser quelles actions, quels identifiants sont utilisés, quelles relations existent entre les objets, comment les différents niveaux de privilèges sont matérialisés et quelles hypothèses de sécurité ont été faites lors de la conception de l’application.

Cette compréhension est indispensable, car certaines des vulnérabilités API les plus critiques sont entièrement dépendantes du contexte. Prenons une requête permettant à un utilisateur de consulter son profil :

GET /api/v1/users/1245/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

D’un point de vue purement syntaxique, la requête ne présente rien d’anormal. Pourtant, le paramètre 1245 constitue immédiatement un point d’intérêt. Le pentester cherchera notamment à déterminer ce qui se produit lorsqu’il remplace cet identifiant par celui d’un autre utilisateur :

GET /api/v1/users/1246/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

Si le serveur vérifie uniquement que le token est valide sans vérifier que l’utilisateur authentifié possède effectivement le droit de consulter l’objet 1246, l’API présente une vulnérabilité de type Broken Object Level Authorization, ou BOLA. L’exploitation ne repose ici sur aucune injection particulière. Elle découle directement d’une erreur dans le modèle d’autorisation.

Cette dimension contextuelle explique pourquoi le pentest manuel reste particulièrement important dans le domaine des API.

Pourquoi les API constituent-elles une surface d’attaque particulière ?

Une application web traditionnelle peut masquer une partie de ses traitements derrière une interface graphique. Une API expose au contraire explicitement les opérations nécessaires au fonctionnement de l’application. Un client mobile peut appeler directement POST /api/transfers pour réaliser un virement. Une plateforme SaaS peut exposer PATCH /api/users/473 pour modifier un utilisateur. Une application e-commerce peut s’appuyer sur POST /api/orders/318/refund pour déclencher un remboursement.

La fonction métier est donc souvent directement accessible sous forme de requête. Le fait qu’un bouton ne soit pas affiché dans le frontend ne constitue aucune protection : un attaquant peut reconstruire, modifier et envoyer lui-même les requêtes.

Les API présentent également plusieurs caractéristiques qui augmentent leur surface d’attaque. Elles manipulent de nombreux identifiants d’objets, fonctionnent souvent avec des tokens, exposent des données structurées faciles à analyser automatiquement et sont fréquemment connectées à des systèmes tiers, des bases de données, des services cloud ou d’autres API internes.

La multiplication des versions et des environnements ajoute une difficulté supplémentaire. Une organisation peut sécuriser correctement /api/v3/ tout en laissant accessible une ancienne version /api/v1/ disposant de contrôles beaucoup plus faibles. Un environnement de staging oublié, une documentation Swagger exposée ou une ancienne gateway peuvent également révéler une surface d’attaque qui n’est plus visible dans l’application principale.

Un pentest API doit donc s’intéresser à l’écosystème dans son ensemble plutôt qu’à une simple collection d’endpoints.

Quels types d’API peuvent être pentestés ?

API REST

Les API REST sont probablement les plus couramment rencontrées lors des pentests applicatifs. Elles reposent généralement sur des ressources manipulées via des méthodes HTTP comme GET, POST, PUT, PATCH ou DELETE, et utilisent fréquemment JSON pour transporter les données.

Le pentest porte notamment sur les endpoints, les paramètres, les objets JSON, les identifiants de ressources, les contrôles d’accès, les méthodes HTTP disponibles et les traitements réalisés par le backend. REST ne définit cependant pas à lui seul le niveau de sécurité de l’API. Deux endpoints visuellement très similaires peuvent appliquer des modèles d’autorisation totalement différents.

API GraphQL

GraphQL modifie sensiblement l’approche. Une API REST expose généralement plusieurs routes représentant différentes ressources. Une API GraphQL concentre souvent une grande partie de ses interactions sur un endpoint unique, par exemple /graphql.

Le pentester ne cherche donc plus seulement à découvrir des endpoints. Il doit comprendre le schéma, les queries, mutations, types, champs, relations et mécanismes d’autorisation disponibles. Cette flexibilité peut introduire des risques particuliers : absence de contrôle d’accès sur certains champs, interrogation de relations imbriquées, requêtes très coûteuses, batching, aliases, introspection, suggestions de champs ou mutations insuffisamment protégées.

API SOAP

Les API SOAP restent présentes dans de nombreux environnements d’entreprise, notamment dans les secteurs utilisant des applications métier historiques. Elles s’appuient sur XML et peuvent exposer leur fonctionnement à travers des fichiers WSDL.

Le pentest porte alors notamment sur les opérations exposées, les schémas XML, les contrôles d’accès, les mécanismes WS-Security, les parsers XML et les traitements réalisés à partir des messages SOAP. Les vulnérabilités XXE, les erreurs de signature XML, les injections dans les données XML ou certaines mauvaises configurations de services peuvent notamment faire partie du périmètre.

API gRPC

gRPC est particulièrement présent dans les architectures modernes reposant sur des microservices. Les échanges utilisent généralement Protocol Buffers plutôt que JSON et peuvent fonctionner avec différents types de flux.

L’évaluation de sécurité nécessite d’identifier les services et méthodes disponibles, de comprendre les messages Protobuf et de tester l’authentification, l’autorisation ainsi que les limites appliquées aux appels. Lorsque gRPC Reflection est disponible, il peut faciliter l’énumération des services, de manière comparable à ce qu’une documentation d’API fournit dans d’autres architectures.

Que teste-t-on lors d’un pentest API ?

Le périmètre exact dépend de l’architecture, des fonctionnalités et des objectifs de l’audit. Certains axes reviennent néanmoins pratiquement systématiquement.

Authentification

Les mécanismes d’authentification déterminent comment l’API établit l’identité de l’utilisateur ou du système qui lui envoie une requête. Le pentester analyse l’ensemble du cycle de vie de cette authentification.

Un formulaire de connexion correctement protégé n’est pas suffisant si un endpoint secondaire permet de contourner ces protections. Il faut donc examiner l’inscription, la récupération de compte, les changements de mot de passe, la MFA, la création des sessions, leur révocation ainsi que les mécanismes OAuth, OpenID Connect, JWT et API keys utilisés par l’application.

Une attention particulière est portée aux différences de comportement. Une application web peut exiger une MFA après l’envoi du mot de passe tandis qu’une ancienne API mobile délivre directement un token après la première étape. Dans ce cas, l’attaquant n’a pas besoin de casser la MFA : il lui suffit d’utiliser le chemin applicatif qui ne l’impose pas.

Autorisation et contrôles d’accès

L’authentification répond à la question « qui est cet utilisateur ? ». L’autorisation doit déterminer « que peut-il faire ? ». Cette distinction est fondamentale dans la sécurité des API. Un utilisateur parfaitement authentifié peut exploiter une API si les permissions sont mal vérifiées.

Le pentester recherche notamment les possibilités d’escalade horizontale, lorsqu’un utilisateur accède aux ressources d’un autre utilisateur ayant les mêmes privilèges, et verticale, lorsqu’il accède à des fonctions réservées à un rôle supérieur.

Dans les plateformes SaaS multi-tenant, une dimension supplémentaire apparaît : l’isolation entre organisations. Une requête telle que :

GET /api/organisations/52/documents HTTP/1.1
Authorization: Bearer <token-organisation-51>

… doit être refusée si le token appartient exclusivement à l’organisation 51. Il ne suffit donc pas de vérifier que l’utilisateur possède le rôle admin. L’application doit également vérifier qu’il possède ce rôle dans l’organisation concernée.

Validation et interprétation des entrées

Une API traite un grand nombre de données contrôlées par l’utilisateur : paramètres d’URL, query strings, headers, cookies, payloads JSON ou XML, fichiers et métadonnées. Le pentester cherche à déterminer comment ces entrées sont interprétées et utilisées.

Les vulnérabilités classiques restent évidemment pertinentes : injections SQL et NoSQL, injections de commandes, injections de code, XXE, SSRF, traversées de répertoires ou désérialisations dangereuses. Mais il faut également analyser les problèmes plus subtils liés au parsing.

Que se passe-t-il lorsqu’un même paramètre est présent deux fois, par exemple ?role=user&role=admin ? Le reverse proxy, le framework et l’application utilisent-ils tous la même valeur ? Que se passe-t-il si l’API attend un entier mais reçoit un tableau, un objet, null, une chaîne vide ou une valeur extrêmement grande ? Ce type de comportement peut révéler des incohérences exploitables que de simples tests d’injection ne permettent pas d’identifier.

Logique métier

La logique métier constitue l’un des domaines où le pentest manuel apporte le plus de valeur. Une vulnérabilité métier n’implique pas nécessairement une erreur technique classique. L’attaquant exploite plutôt une fonctionnalité légitime d’une manière qui n’avait pas été anticipée.

Une plateforme de paiement peut par exemple calculer correctement une transaction mais autoriser la modification du montant entre deux étapes du workflow. Une plateforme commerciale peut appliquer correctement un coupon mais permettre de l’utiliser plusieurs fois. Un système de réservation peut empêcher l’achat d’un article indisponible tout en restant vulnérable à des requêtes concurrentes déclenchées au même moment.

Comprendre ces scénarios nécessite de reconstruire les règles qui gouvernent l’application et de rechercher les hypothèses implicites utilisées par les développeurs.

Rate limiting et consommation de ressources

Le rate limiting ne doit pas être analysé uniquement sur l’endpoint de connexion. De nombreuses fonctionnalités peuvent être détournées par automatisation : récupération de compte, vérification d’OTP, recherche, génération de documents, exports, envoi de messages, invitations, achats, réservations ou traitements lourds.

Le pentester cherche à déterminer si la limitation est réellement associée à l’action sensible. Une restriction fondée uniquement sur l’adresse IP peut être insuffisante. Une restriction appliquée à un token peut être contournée si l’attaquant peut créer de nombreux comptes. Une limite appliquée à un endpoint peut être inutile lorsqu’une seconde route permet d’exécuter la même action.

Il faut également s’intéresser au coût réel de l’opération. Cinq requêtes de génération de rapports peuvent parfois être plus dangereuses que plusieurs centaines de requêtes simples.

Chiffrement, tokens et données sensibles

Les API reposent très fréquemment sur des tokens. Le pentester vérifie leur génération, leur intégrité, leur durée de vie, leur révocation, leur périmètre et les informations qu’ils contiennent.

Une analyse correcte ne consiste pas seulement à décoder un JWT. Un JWT est conçu pour pouvoir être décodé par son destinataire ; l’enjeu est de vérifier qu’il est correctement signé, que le serveur valide cette signature et que les claims déterminants sont effectivement vérifiés.

Les règles de durée de vie, d’audience, d’émetteur, de scope ou de révocation sont souvent aussi importantes que l’algorithme cryptographique lui-même. Le pentest vérifie également la configuration TLS, l’exposition de secrets dans les réponses, les logs, le code client ou les messages d’erreur, ainsi que la manière dont les tokens sont transportés et stockés.

Méthodologie d’un pentest API

Un pentest API efficace suit généralement plusieurs phases. Celles-ci ne sont pas totalement linéaires : une information obtenue pendant l’exploitation peut conduire à reprendre l’énumération ou à découvrir une nouvelle surface d’attaque.

Cadrage et préparation

Avant les tests, le périmètre doit être défini précisément. Il peut inclure une ou plusieurs URL d’API, une documentation OpenAPI, plusieurs rôles utilisateurs, des applications mobiles consommant l’API, un environnement de test, certains microservices ou certaines briques d’infrastructure.

Il est également important d’identifier les fonctionnalités présentant un risque opérationnel particulier. Une API permettant de déclencher des paiements, d’envoyer des e-mails à des milliers d’utilisateurs ou de supprimer des données nécessite des précautions différentes d’une API de consultation.

Lorsque l’audit est réalisé sur un environnement de production, ces contraintes doivent être intégrées à la stratégie de test : volumes de requêtes, opérations destructrices, création de comptes, notifications et traitement de données réelles doivent être maîtrisés.

Reconnaissance et découverte de la surface d’attaque

La première phase technique consiste à identifier les API accessibles et les informations permettant d’en comprendre le fonctionnement. Le pentester peut analyser les sous-domaines, applications web, bundles JavaScript, applications mobiles, portails développeurs et documentations publiques.

Certaines routes conventionnelles méritent également d’être recherchées :

/swagger
/swagger-ui
/swagger.json
/openapi.json
/api-docs
/graphql
/graphiql

La présence d’une documentation Swagger ou OpenAPI accessible publiquement ne constitue pas automatiquement une vulnérabilité. Elle devient toutefois importante lorsque cette exposition n’était pas prévue ou qu’elle révèle des fonctions sensibles, des endpoints d’administration, des paramètres internes ou des environnements oubliés.

La reconnaissance doit également rechercher les anciennes versions de l’API, par exemple /api/v1/, /api/v2/ et /api/v3/. Une version obsolète mais toujours accessible peut constituer une surface d’attaque particulièrement intéressante lorsque les corrections de sécurité n’y ont pas été répercutées.

Énumération et cartographie de la surface d’attaque

Une fois les principales interfaces identifiées, le pentester reconstruit leur fonctionnement. Pour chaque opération, il cherche à comprendre les méthodes HTTP autorisées, paramètres, objets, headers nécessaires, types attendus, réponses et rôles utilisateurs capables de l’utiliser.

Cette cartographie permet également d’identifier les relations entre ressources. Si une application manipule des utilisateurs, organisations, projets, documents et factures, il devient nécessaire de comprendre quels objets appartiennent à quels utilisateurs et quelles relations devraient être interdites.

Les outils d’interception et de découverte permettent d’accélérer cette phase, mais la cartographie reste un travail de compréhension. Une route qui semble secondaire peut exposer la même donnée qu’une route principale avec des contrôles différents.

Analyse des vulnérabilités et des mécanismes de sécurité

Une fois le fonctionnement compris, les différents mécanismes sont soumis à des tests offensifs. Le pentester modifie les identifiants, paramètres, propriétés JSON, tokens, rôles, séquences d’appels et méthodes HTTP. Il compare également le comportement observé avec plusieurs comptes afin de détecter les incohérences de permissions.

Les tests automatisés peuvent être utilisés pour accélérer le fuzzing ou rechercher certains comportements, mais les résultats doivent être replacés dans le contexte de l’application. Un code 200 OK n’est pas un problème en soi ; il le devient lorsque la donnée retournée ne devrait pas être accessible à cet utilisateur.

Exploitation et validation de l’impact

Une vulnérabilité potentielle doit ensuite être validée de manière contrôlée. L’objectif n’est pas uniquement de démontrer qu’un contrôle est absent, mais d’évaluer ce que cette absence permet réellement d’obtenir.

Une BOLA permettant de consulter un nom d’utilisateur n’a pas le même impact qu’une BOLA permettant de récupérer l’ensemble des documents confidentiels d’une organisation. De même, une SSRF permettant seulement d’effectuer une requête vers une destination externe ne présente pas nécessairement le même niveau de risque qu’une SSRF donnant accès à des services internes sensibles.

Cette phase transforme une anomalie technique en scénario d’attaque compréhensible et permet d’évaluer la gravité en tenant compte de l’exploitabilité, de l’exposition et de l’impact métier.

Post-exploitation et chaînes d’attaque

Lorsque le contexte de l’audit l’autorise, le pentester cherche également à déterminer si plusieurs vulnérabilités peuvent être combinées.

Une fuite de données peut révéler des identifiants internes. Ces identifiants peuvent ensuite être utilisés pour exploiter une BOLA. L’accès obtenu peut révéler une intégration permettant d’effectuer des requêtes côté serveur. Cette intégration peut elle-même exposer des services internes.

Ce travail de chaînage est particulièrement important, car le risque réel d’une vulnérabilité dépend souvent de son interaction avec le reste du système. Une faiblesse considérée isolément comme modérée peut devenir critique lorsqu’elle sert de point d’entrée à un chemin d’attaque plus large.

Rapport, recommandations et contre-tests

Le rapport doit permettre aux équipes de comprendre la vulnérabilité, de la reproduire et de la corriger. Chaque finding doit idéalement présenter le contexte, les prérequis, la requête utilisée, le comportement observé, le scénario d’exploitation, l’impact et les recommandations adaptées au fonctionnement réel de l’application.

Les recommandations ne doivent pas seulement décrire une protection générique. Pour une BOLA, il faut préciser où l’autorisation doit être appliquée et quelle relation doit être vérifiée. Pour une SSRF, il faut identifier les destinations réellement nécessaires et le comportement attendu du client HTTP. Pour une race condition, la correction doit être conçue au niveau où l’atomicité peut effectivement être garantie.

Une fois les corrections déployées, un contre-test permet de vérifier qu’elles bloquent effectivement le scénario initial sans introduire une simple protection superficielle.

Focus sur l’OWASP API Security Top 10, un référentiel essentiel pour le pentest API

L’OWASP API Security Top 10 constitue l’un des référentiels les plus utilisés pour structurer l’analyse des risques spécifiques aux API. L’édition 2023 comprend dix catégories : Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management et Unsafe Consumption of APIs.

Ce référentiel fournit une excellente grille de lecture, mais il ne doit pas être utilisé comme une checklist exhaustive. Une API peut présenter des vulnérabilités critiques qui ne correspondent pas exactement à l’une de ces catégories, notamment des injections, des race conditions ou des vulnérabilités propres à une technologie particulière.

API1:2023 – Broken Object Level Authorization (BOLA)

La BOLA apparaît lorsqu’une API utilise un identifiant contrôlé par l’utilisateur pour accéder à une ressource sans vérifier correctement qu’il possède le droit d’accéder à cette ressource.

Prenons une requête légitime :

GET /api/v1/invoices/8041 HTTP/1.1
Authorization: Bearer <token-user-A>

L’utilisateur A est propriétaire de la facture 8041. Le pentester essaie ensuite un autre identifiant :

GET /api/v1/invoices/8042 HTTP/1.1
Authorization: Bearer <token-user-A>

Si la facture 8042 appartient à l’utilisateur B et que l’API la retourne malgré tout, la vulnérabilité est confirmée.

La difficulté ne réside pas nécessairement dans la prédictibilité des identifiants. Même des UUID peuvent être exploités s’ils sont obtenus à travers une autre fonctionnalité, une fuite de données ou une relation entre objets. Remplacer un identifiant numérique par un UUID peut donc compliquer l’énumération, mais ne corrige pas l’autorisation.

La protection doit reposer sur une vérification côté serveur de la relation entre l’identité authentifiée et l’objet demandé. Dans un environnement multi-tenant, cette vérification doit également inclure l’organisation ou le tenant concerné.

API2:2023 – Broken Authentication

Cette catégorie couvre les erreurs permettant à un attaquant d’usurper l’identité d’un utilisateur ou de compromettre ses mécanismes d’authentification. Les scénarios peuvent concerner les mots de passe, sessions, JWT, API keys, mécanismes MFA, reset de mot de passe ou intégrations OAuth.

Prenons un endpoint de vérification MFA :

POST /api/auth/mfa HTTP/1.1
Content-Type: application/json

{
  "code": "123456"
}

Si aucune limitation n’est appliquée et qu’un attaquant peut tester automatiquement les différentes combinaisons, la sécurité apportée par le second facteur peut être fortement diminuée.

Le pentest recherche également les différences entre interfaces. Une MFA parfaitement appliquée sur le frontend principal ne protège pas l’application si une ancienne API mobile contourne cette étape. De même, un logout ne protège pas réellement l’utilisateur si les tokens précédemment émis restent utilisables pendant une durée excessive.

La remédiation doit couvrir l’ensemble du cycle de vie : authentification initiale, limitation des tentatives, récupération de compte, MFA, émission et révocation des tokens, invalidation lors d’événements sensibles et cohérence entre tous les clients de l’API.

API3:2023 – Broken Object Property Level Authorization (BOPLA)

Cette catégorie regroupe notamment deux problématiques historiquement traitées séparément : l’exposition excessive de données et le Mass Assignment. L’idée commune est qu’un utilisateur dispose d’un accès incorrect à certaines propriétés d’un objet.

Dans le cas de la lecture, l’API peut retourner plus d’informations que nécessaire :

{
  "id": 1521,
  "name": "John Smith",
  "email": "john@example.com",
  "role": "user",
  "password_hash": "$2y$10$...",
  "mfa_secret": "ABCD1234",
  "internal_notes": "VIP customer"
}

Le frontend peut décider de n’afficher que name et email, mais cela ne protège pas les autres champs. Tout utilisateur capable d’appeler directement l’API peut lire la réponse complète.

Dans le cas de l’écriture, l’utilisateur peut parvenir à modifier une propriété qui ne devrait jamais lui être accessible. Une requête légitime peut être :

{
  "name": "John Smith",
  "email": "john@example.com"
}

Le pentester essaie alors :

{
  "name": "John Smith",
  "email": "john@example.com",
  "role": "admin"
}

Si le framework associe automatiquement toutes les propriétés reçues à l’objet backend et que role n’est pas explicitement interdit, une escalade de privilèges devient possible.

La remédiation consiste à définir explicitement les propriétés consultables et modifiables dans chaque contexte, plutôt qu’à faire confiance au modèle de données complet ou au fait que le frontend n’affiche pas certaines valeurs.

API4:2023 – Unrestricted Resource Consumption

Certaines requêtes API peuvent consommer des ressources importantes : CPU, mémoire, espace disque, bande passante, accès à une base de données ou appels facturés auprès d’un prestataire tiers. Une attaque n’a donc pas nécessairement besoin de saturer l’intégralité du réseau pour provoquer un impact.

Une API de génération de rapport peut accepter :

POST /api/reports/generate HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "from": "2026-01-01",
  "to": "2026-01-31"
}

Le pentester peut ensuite demander une période beaucoup plus importante ou déclencher plusieurs générations simultanées. Si chaque rapport provoque des requêtes lourdes, une génération PDF et un stockage objet, un petit nombre d’appels peut suffire à créer une consommation disproportionnée de ressources.

Les GraphQL APIs sont également concernées lorsqu’elles acceptent des requêtes profondément imbriquées ou extrêmement complexes. Les limites doivent donc être adaptées au coût réel de l’opération : quotas par utilisateur ou tenant, pagination, limites de taille, timeouts, analyse de complexité, contrôle du nombre d’opérations et restrictions sur les fonctionnalités coûteuses.

API5:2023 – Broken Function Level Authorization (BFLA)

Une BOLA concerne l’accès à un objet particulier. Une Broken Function Level Authorization concerne l’accès à une fonction qui devrait être réservée à un autre rôle.

Un administrateur peut légitimement supprimer un utilisateur :

DELETE /api/admin/users/913 HTTP/1.1
Authorization: Bearer <admin-token>

Le pentester répète la requête avec un token standard :

DELETE /api/admin/users/913 HTTP/1.1
Authorization: Bearer <user-token>

Une API correctement protégée doit refuser l’opération, typiquement avec un 403 Forbidden.

Le fait que le frontend n’affiche pas le bouton « Supprimer » aux utilisateurs standards n’entre pas dans le modèle de sécurité. L’autorisation doit être appliquée à l’opération elle-même, côté serveur, en tenant compte du rôle, du contexte et, si nécessaire, du tenant.

API6:2023 – Unrestricted Access to Sensitive Business Flows

Certaines fonctionnalités sont dangereuses non pas parce qu’elles contiennent une vulnérabilité technique, mais parce qu’elles peuvent être automatisées ou détournées à grande échelle.

Un système de réservation peut, par exemple, permettre à un utilisateur de réserver un produit rare :

POST /api/reservations HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "productId": "limited-2026"
}

Chaque réservation peut être parfaitement valide. Pourtant, si un utilisateur peut réserver automatiquement la totalité du stock disponible, il peut empêcher les clients légitimes d’utiliser le service.

Le même problème existe avec la création massive de comptes, l’envoi d’invitations, les votes, les coupons promotionnels, l’achat de produits limités ou certaines fonctionnalités financières.

La correction dépend du métier. Il peut être nécessaire de limiter les opérations par utilisateur, d’introduire des quotas, de détecter certains comportements automatisés ou d’ajouter des contrôles spécifiques. Il n’existe pas de protection universelle applicable à tous les business flows.

API7:2023 – Server-Side Request Forgery (SSRF)

Une SSRF survient lorsqu’une donnée contrôlée par l’utilisateur influence une requête effectuée par le serveur.

Prenons une fonctionnalité d’import d’image :

POST /api/images/import HTTP/1.1
Content-Type: application/json

{
  "url": "https://cdn.example.com/avatar.jpg"
}

Le pentester remplace l’URL par une destination contrôlée afin de confirmer que le serveur effectue lui-même la requête. Il cherche ensuite, dans les limites du pentest, à déterminer si cette fonctionnalité permet d’atteindre des ressources internes qui ne devraient pas être accessibles depuis l’extérieur.

Dans AWS, l’adresse 169.254.169.254 est fréquemment utilisée pour illustrer l’accès au service de métadonnées EC2. Les environnements utilisant IMDSv2 nécessitent toutefois l’obtention d’un token spécifique avant l’accès aux métadonnées, ce qui peut empêcher certaines SSRF simples d’exploiter directement ce service.

L’analyse ne doit donc jamais s’arrêter à la présence d’un paramètre ressemblant à une URL. Le pentester doit comprendre quel client HTTP est utilisé, quels protocoles sont acceptés, comment les redirections sont gérées, à quel moment la résolution DNS intervient et quelles destinations sont accessibles depuis le serveur.

Une correction naïve consistant à bloquer uniquement localhost et 127.0.0.1 est insuffisante. Une politique robuste doit déterminer quelles destinations sont réellement nécessaires au fonctionnement de la fonctionnalité et refuser les autres, tout en prenant en compte les adresses privées, redirections, formats alternatifs d’adresses IP et comportements de résolution.

API8:2023 – Security Misconfiguration

Les mauvaises configurations peuvent apparaître au niveau de l’API elle-même, du framework, du reverse proxy, de l’API gateway ou de l’infrastructure.

Des environnements de debug exposés peuvent notamment révéler des routes internes, variables d’environnement, stack traces, source paths ou informations de configuration. Un exemple fréquent en black box est celui d’une application Symfony laissée avec des mécanismes de debug ou de profiler accessibles en production. Ces interfaces peuvent fournir suffisamment d’informations pour accélérer considérablement la découverte de routes, de paramètres ou de secrets.

Les politiques CORS doivent également être analysées lorsqu’une API est utilisée depuis un navigateur. Une configuration dangereuse peut refléter arbitrairement l’origine d’un site malveillant tout en autorisant l’envoi de credentials :

Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Credentials: true

À l’inverse, la combinaison Access-Control-Allow-Origin: * avec Access-Control-Allow-Credentials: true ne permet pas, dans un navigateur conforme, de lire une réponse authentifiée avec credentials. Elle ne doit donc pas être utilisée comme démonstration d’un scénario CORS exploitable.

Les erreurs détaillées constituent un autre point d’attention :

{
  "error": "SQL syntax error near SELECT * FROM users"
}

Même lorsqu’elles ne provoquent pas directement une compromission, elles peuvent faciliter considérablement la reconnaissance et l’exploitation d’autres vulnérabilités.

API9:2023 – Improper Inventory Management

L’un des problèmes les plus sous-estimés concerne l’inventaire des API. Au fil des évolutions, une organisation peut maintenir plusieurs versions, environnements, sous-domaines ou gateways. Une API qui n’est plus utilisée par le frontend peut rester exposée plusieurs années.

Par exemple :

api.example.com/v3/
legacy-api.example.com/v1/
staging-api.example.com/
partner-api.example.com/

La version actuelle peut bénéficier de contrôles robustes alors que /v1/ accepte encore d’anciens tokens ou expose des endpoints supprimés depuis longtemps. Le pentest cherche donc également ce qui a été oublié : versions anciennes, environnements de test, services shadow IT, routes dépréciées et documentations encore accessibles.

La remédiation passe par un inventaire maintenu, une politique de versioning, la suppression effective des services obsolètes et une surveillance de l’exposition externe.

API10:2023 – Unsafe Consumption of APIs

Les applications modernes consomment elles-mêmes de nombreuses API tierces. Une erreur fréquente consiste à considérer les données reçues de ces services comme intrinsèquement fiables.

Pourtant, une API tierce peut être compromise, détournée ou simplement retourner des données inattendues. Si l’application récupère une valeur auprès d’un fournisseur puis l’insère directement dans une requête SQL, une commande système, un template ou une page HTML sans appliquer les protections adaptées au contexte, une vulnérabilité peut apparaître même si l’utilisateur final ne contrôle pas directement la donnée initiale.

Le pentest doit donc considérer les données provenant des services externes comme une entrée potentiellement non fiable. Il faut également analyser la gestion des redirections, les certificats TLS, les timeouts, les limites de taille, les schémas de réponse et la manière dont l’application réagit lorsque l’API tierce renvoie des informations inattendues.

Authentification avancée : JWT, OAuth 2.0 et OpenID Connect

Les mécanismes d’authentification et de fédération deviennent rapidement complexes dans les architectures modernes. Une implémentation peut être cryptographiquement correcte tout en prenant une mauvaise décision d’autorisation à cause d’un claim mal validé, d’une audience incorrecte ou d’un flux OAuth mal configuré.

Analyse approfondie des JWT

Un JWT contient généralement un header, un payload et une signature. Le fait de pouvoir décoder son contenu n’est pas une vulnérabilité : le payload d’un JWT signé n’est généralement pas chiffré. La sécurité repose sur la validation cryptographique et sur l’interprétation correcte des claims.

Le pentester vérifie notamment que le serveur contrôle réellement les claims temporels comme exp et nbf, ainsi que les claims de contexte comme iss, aud et sub. Un token correctement signé pour une autre application ne doit pas nécessairement être accepté par l’API ciblée.

La sélection de la clé de signature mérite également une analyse. Un header peut contenir :

{
  "alg": "RS256",
  "kid": "key-2026-01"
}

Le problème n’est pas intrinsèquement lié au champ kid, mais à la manière dont le serveur l’utilise. Une implémentation dangereuse peut l’intégrer directement dans un chemin de fichier, une requête ou un mécanisme externe sans validation suffisante.

Les architectures utilisant des signatures asymétriques exposent souvent un JWKS contenant les clés publiques nécessaires à la validation. Le pentester vérifie comment ces clés sont récupérées, mises en cache et sélectionnées, ainsi que les sources considérées comme fiables.

Enfin, la révocation doit être testée dans le contexte réel. Si un utilisateur change son mot de passe mais qu’un ancien access token reste valable pendant plusieurs jours, un attaquant ayant volé ce token conserve son accès. Le risque dépend alors directement de sa durée de vie et de ses permissions.

Comprendre OAuth 2.0 et OpenID Connect avant de les tester lors d’un pentest API

OAuth 2.0 est avant tout un framework de délégation d’autorisation. OpenID Connect ajoute une couche d’identité permettant à une application d’authentifier un utilisateur à travers un fournisseur d’identité.

Dans un scénario classique, plusieurs composants interviennent. Le resource owner est généralement l’utilisateur. Le client est l’application cherchant à accéder à une ressource au nom de cet utilisateur. L’authorization server gère l’authentification et délivre les tokens. Le resource server correspond à l’API qui accepte l’access token.

Cette séparation est importante, car les contrôles de sécurité doivent être cohérents entre plusieurs systèmes. Lors d’un pentest API, il est indispensable de reconstruire précisément le flux utilisé avant d’essayer d’identifier des vulnérabilités.

Analyse d’un Authorization Code Flow lors d’un pentest API

Un flux peut commencer par une redirection telle que :

GET /authorize?response_type=code&client_id=client-123&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&scope=openid%20profile&state=a8f29c HTTP/1.1
Host: idp.example.com

Après authentification, l’authorization server renvoie l’utilisateur vers :

https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=a8f29c

L’application échange ensuite le code contre un token auprès du token endpoint. Chaque étape introduit des décisions de sécurité qui doivent être testées.

Validation de redirect_uri

Le paramètre redirect_uri détermine où l’utilisateur sera renvoyé après l’authentification. Une configuration sûre doit contrôler précisément les destinations autorisées.

Une validation trop permissive peut accepter une destination contrôlée par l’attaquant ou être contournée à l’aide d’un sous-domaine, d’une comparaison partielle ou d’une redirection ouverte présente sur un domaine autorisé. Le risque dépend ensuite du flux utilisé et des données transmises à cette destination.

Le pentester doit donc analyser la validation exacte. Les bonnes pratiques modernes privilégient une comparaison stricte des URI préenregistrées plutôt qu’une validation approximative par préfixe ou expression permissive.

state, PKCE et protection du flux d’autorisation

Le paramètre state permet notamment au client de lier une réponse OAuth à une requête qu’il avait précédemment initiée. S’il est absent, prévisible ou insuffisamment vérifié, certains scénarios de CSRF ou de login CSRF peuvent devenir possibles.

PKCE ajoute une protection importante contre l’injection et le détournement de codes d’autorisation. Le client génère une valeur aléatoire appelée code_verifier, puis envoie une dérivation appelée code_challenge lors de la demande d’autorisation. Lors de l’échange du code, il doit présenter le code_verifier correspondant.

Le pentester vérifie que PKCE est réellement exigé lorsque nécessaire et que les paramètres ne peuvent pas simplement être supprimés du flux. Les recommandations de sécurité OAuth actuelles imposent PKCE aux clients publics et le recommandent aussi pour les clients confidentiels.

Scopes, audience et émetteur

Les scopes définissent généralement les permissions demandées par le client. Un token disposant uniquement de read:documents ne devrait pas être accepté pour une opération telle que :

DELETE /api/documents/813 HTTP/1.1
Authorization: Bearer <read-only-token>

Le contrôle ne doit donc pas être effectué uniquement lors de la génération du token. Chaque API doit interpréter correctement les permissions qui lui sont associées.

L’audience permet d’indiquer à quel service un token est destiné. Un token délivré uniquement pour api-profile.example.com ne devrait pas nécessairement permettre d’accéder à api-payments.example.com. Le pentester teste donc si un token obtenu pour un service peut être réutilisé sur un autre.

Le claim iss permet quant à lui d’identifier l’émetteur du token. Une API ne doit pas accepter un token simplement parce que sa signature est mathématiquement valide si celui-ci provient d’un fournisseur d’identité qui n’est pas considéré comme fiable dans ce contexte.

ID token, access token et nonce

OpenID Connect introduit notamment l’ID token. L’ID token fournit au client des informations relatives à l’identité de l’utilisateur. L’access token est destiné à autoriser l’accès à une ressource.

Ces deux objets ne sont pas interchangeables par principe. Une API qui accepte un ID token là où elle devrait exiger un access token peut introduire des problèmes de sécurité, notamment si les audiences, scopes et finalités diffèrent.

Dans certains flux OpenID Connect, nonce permet de lier l’ID token à la demande d’authentification initiée par le client. Le pentester vérifie si cette valeur est générée avec suffisamment d’entropie, correctement associée à la transaction et réellement contrôlée lorsque le flux l’exige.

Refresh tokens et prévention du rejeu

Les refresh tokens méritent une attention particulière, car leur durée de vie est souvent supérieure à celle des access tokens. Le pentester analyse leur stockage, leur rotation et leur révocation.

Lorsqu’un mécanisme de rotation est utilisé, la réutilisation d’un ancien refresh token peut constituer un signal de compromission. Une application qui continue à accepter indéfiniment tous les refresh tokens précédemment émis augmente considérablement l’impact d’un vol de credentials.

Les architectures les plus sensibles peuvent également utiliser des mécanismes de sender-constrained tokens, par exemple mTLS ou DPoP, afin de limiter la réutilisation d’un access token volé depuis un autre client.

Confusion entre plusieurs clients et endpoints de découverte

Un même authorization server peut desservir plusieurs applications. Le pentester vérifie qu’un code ou un token destiné au client A ne peut pas être utilisé par le client B lorsque cela n’est pas prévu. Ces erreurs apparaissent notamment lorsque les identifiants de clients, redirect URI, issuers ou audiences ne sont pas correctement corrélés.

De nombreux fournisseurs exposent une configuration telle que /.well-known/openid-configuration. Cette exposition est normale et utile au fonctionnement d’OpenID Connect. Elle constitue néanmoins une source d’information précieuse pendant un pentest, car elle permet de reconstruire rapidement les endpoints d’autorisation, de token, de révocation et la configuration cryptographique du fournisseur.

API keys

Les API keys restent courantes, notamment pour les intégrations machine-to-machine. Le pentester cherche à déterminer où elles sont stockées, comment elles sont transmises, quelles permissions elles accordent et si elles peuvent être renouvelées ou révoquées.

Une API key incluse dans une application mobile ou un bundle JavaScript accessible publiquement ne peut généralement pas être considérée comme un secret fiable. L’impact dépend cependant de ses permissions : une clé publique destinée à identifier une application n’a pas le même risque qu’une clé donnant accès à des fonctions administratives.

Exploitation de vulnérabilités d’injection lors d’un pentest API

Même si l’OWASP API Security Top 10 met fortement l’accent sur l’autorisation et la logique métier, les injections restent évidemment pertinentes.

Injections SQL et NoSQL

Prenons par exemple :

GET /api/users?email=test@example.com HTTP/1.1
Host: api.example.com

Si la valeur du paramètre est concaténée directement dans une requête SQL, une injection peut apparaître. Le même principe existe avec certaines bases NoSQL lorsqu’un objet JSON contrôlé par l’utilisateur est interprété comme une expression plutôt que comme une simple valeur.

Le pentest doit donc comprendre comment l’entrée traverse l’application et comment elle est finalement utilisée par le backend. La présence d’un ORM ou d’une couche d’abstraction ne garantit pas automatiquement l’absence d’injection si des requêtes dynamiques ou des opérateurs contrôlés par l’utilisateur sont utilisés.

Injection de commandes et injection de code

Une attention particulière doit être portée aux fonctions qui exécutent des interpréteurs, moteurs de templates ou commandes système.

Considérons :

calculate(formula) {
  return eval(`(function() { return ${formula}; }())`);
}

La variable formula est injectée directement dans eval(). Le problème initial est ici une injection de code JavaScript. Puisque le contexte Node.js peut permettre d’utiliser des fonctionnalités telles que child_process, cette injection de code peut ensuite conduire à une exécution de commandes système et potentiellement à une RCE complète.

Cette distinction est importante : l’appel dangereux est eval() et la cause racine est l’exécution dynamique d’une donnée contrôlée par l’utilisateur. L’exécution de commandes constitue ensuite une conséquence possible de la compromission.

XXE et parsers XML

Les API utilisant XML peuvent être exposées aux vulnérabilités XXE lorsque le parser autorise certaines entités externes dangereuses. Selon le contexte, un attaquant peut tenter de provoquer l’accès à des fichiers locaux ou à des ressources réseau depuis le serveur.

Les API SOAP constituent un environnement classique pour rechercher ce type de faiblesse, mais toute fonctionnalité acceptant du XML doit être analysée. Le pentester doit également s’intéresser aux transformations XSLT, aux schémas XML, aux mécanismes de signature et aux différences de parsing entre composants.

Problèmes de parsing et comportements HTTP inattendus

Les vulnérabilités API ne proviennent pas toujours du traitement métier lui-même. Des différences d’interprétation entre composants peuvent créer des comportements inattendus et parfois contourner des contrôles placés à un autre niveau de l’architecture.

HTTP Parameter Pollution

Une application peut recevoir :

?user=123&user=456

Différents composants peuvent interpréter ce paramètre différemment. Certains conservent la première valeur, d’autres la dernière, d’autres encore construisent un tableau.

Si un proxy de sécurité valide 123 mais que l’application utilise 456, une divergence de parsing peut permettre de contourner un contrôle. Le pentest cherche donc à comparer le comportement des différents niveaux : CDN, WAF, reverse proxy, framework et logique applicative.

Content-Type confusion

Une route conçue pour accepter Content-Type: application/json peut parfois également interpréter application/x-www-form-urlencoded, text/plain ou application/xml.

Ces variantes peuvent conduire à emprunter des chemins de parsing différents et potentiellement à contourner des validations appliquées uniquement au format prévu. Le pentester vérifie donc quels content types sont réellement acceptés et si les contrôles sont cohérents entre eux.

HTTP method override et méthodes inattendues

Certaines applications prennent en charge des mécanismes comme X-HTTP-Method-Override ou un paramètre _method. Une requête POST peut alors être interprétée en interne comme un PUT ou un DELETE.

Si les contrôles de sécurité sont appliqués sur la méthode externe plutôt que sur l’opération réellement exécutée, cette fonctionnalité peut introduire des contournements. Il faut également tester les méthodes HTTP non prévues, les routes disponibles sous plusieurs verbes et les incohérences entre PUT, PATCH et POST.

Race conditions et attaques concurrentes

Les race conditions apparaissent lorsque le résultat d’une opération dépend de l’ordre ou du moment exact où plusieurs traitements concurrents sont exécutés. Elles sont particulièrement intéressantes dans les API, car un attaquant peut facilement automatiser l’envoi de requêtes simultanées.

Le problème apparaît souvent lorsqu’une application réalise séparément une vérification puis une modification.

Scénario : double utilisation d’un coupon

Imaginons une plateforme e-commerce proposant un coupon PROMO50 utilisable une seule fois. L’utilisateur envoie :

POST /api/cart/apply-coupon HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "coupon": "PROMO50"
}

Le backend suit conceptuellement trois étapes : il vérifie que le coupon n’a pas encore été utilisé, applique la réduction, puis marque le coupon comme utilisé.

Lorsqu’une seule requête est envoyée, tout fonctionne correctement. Le problème apparaît si plusieurs requêtes atteignent le serveur presque simultanément. Deux workers différents peuvent vérifier l’état du coupon avant que l’un ou l’autre ne l’ait marqué comme utilisé. Les deux constatent alors que le coupon est disponible et les deux appliquent la réduction.

La vulnérabilité ne vient pas d’un mauvais contrôle de permissions. Elle vient du fait que la vérification et la modification ne sont pas atomiques.

Scénarios financiers, quotas et tokens à usage unique

Le même problème peut affecter un solde. Si un compte dispose de 100 euros et que deux demandes de retrait de 100 euros sont envoyées simultanément, deux workers peuvent chacun constater que le solde est suffisant avant que la première modification ne soit enregistrée.

Les quotas sont également concernés. Un utilisateur disposant d’une invitation restante peut parfois déclencher plusieurs invitations simultanées si chaque requête vérifie séparément le quota avant de le décrémenter.

Les tokens à usage unique peuvent enfin être vulnérables à la même logique. Deux requêtes simultanées peuvent parfois utiliser le même token de réinitialisation avant que sa consommation ne soit enregistrée.

Comment corriger une race condition

La correction doit généralement intervenir au niveau où la cohérence de la donnée peut réellement être garantie. Une simple condition applicative telle que if balance >= amount ne suffit pas si plusieurs processus peuvent l’exécuter en parallèle.

Selon la technologie et le scénario, la remédiation peut nécessiter des transactions, des verrous, des contraintes de base de données, des opérations atomiques, un mécanisme d’idempotence ou une stratégie adaptée de contrôle de concurrence.

L’élément essentiel consiste à faire en sorte que la vérification de l’état et sa modification ne puissent pas être séparées par une opération concurrente permettant de contourner la règle métier.

Spécificités des pentests API REST

Les API REST nécessitent une attention particulière aux identifiants d’objets, aux méthodes HTTP, à la sérialisation des ressources et aux différentes représentations disponibles.

Une route GET /api/users/1245 peut être correctement protégée alors que PATCH /api/users/1245 ne l’est pas. Le pentester ne doit donc jamais considérer qu’une autorisation observée pour une méthode s’applique automatiquement aux autres.

Les filtres et fonctionnalités de recherche méritent également une attention particulière. Une API peut empêcher l’accès direct à une ressource tout en exposant les mêmes informations à travers /api/search, /api/export ou /api/reports. L’objectif est donc d’identifier toutes les fonctions donnant directement ou indirectement accès au même objet.

La gestion de la pagination, des tris et des filtres peut aussi révéler des informations inattendues. Une limite appliquée à une ressource peut être contournée si l’endpoint d’export ne réutilise pas les mêmes règles. De la même manière, certaines propriétés peuvent être masquées dans une réponse standard mais apparaître dans une route de recherche ou d’administration insuffisamment protégée.

Pentest des API GraphQL : méthodologie et scénarios avancés

GraphQL nécessite une approche différente de celle utilisée pour une API REST classique. Dans une architecture REST, le pentester commence généralement par identifier les endpoints disponibles et les différentes méthodes permettant d’interagir avec les ressources. Avec GraphQL, une grande partie de la surface fonctionnelle peut être concentrée derrière un endpoint unique, souvent /graphql.

La difficulté n’est donc pas seulement de découvrir l’interface, mais de comprendre le modèle de données qu’elle expose : types, champs, queries, mutations, relations entre objets, arguments et règles d’autorisation.

Identifier une API GraphQL

Une API GraphQL est parfois facilement identifiable grâce à des routes conventionnelles telles que /graphql, /graphiql, /graphql-api ou /api/graphql. Cependant, le nom de la route ne suffit pas toujours.

L’analyse du trafic d’une application web ou mobile permet souvent d’identifier des requêtes contenant une propriété query :

POST /graphql HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "query": "query GetProfile { currentUser { id name email } }"
}

Les réponses GraphQL possèdent également une structure caractéristique, généralement organisée autour de propriétés comme data et errors.

Énumération avec l’introspection

GraphQL fournit nativement un mécanisme d’introspection permettant à un client d’interroger le schéma. Une requête minimale peut rechercher les types exposés :

POST /graphql HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "query": "{ __schema { types { name } } }"
}

Lorsque l’introspection est activée, il devient possible de récupérer beaucoup plus d’informations : queries disponibles, mutations, arguments attendus, types de retour, objets imbriqués et relations entre ressources.

L’introspection n’est pas à elle seule une vulnérabilité critique. GraphQL est conçu autour d’un schéma que les clients doivent comprendre. La sécurité ne doit donc jamais dépendre exclusivement du fait que ce schéma soit secret. Son exposition devient surtout intéressante lorsqu’elle révèle des fonctionnalités sensibles ou facilite l’exploitation d’un véritable défaut de contrôle d’accès.

Reconstruire le schéma lorsque l’introspection est désactivée

La désactivation de l’introspection ne signifie pas que le schéma est impossible à reconstruire. Les messages d’erreur constituent parfois une première source d’information.

Une requête invalide comme :

{
  "query": "query { system }"
}

… peut provoquer une réponse de suggestion :

{
  "errors": [
    {
      "message": "Cannot query field 'system'. Did you mean 'systemHealth' or 'systemConfig'?"
    }
  ]
}

La suggestion révèle déjà deux noms de champs valides. En répétant cette approche avec différents noms et en automatisant prudemment les requêtes, il est parfois possible de reconstruire une partie du schéma.

D’autres sources peuvent être exploitées : code JavaScript du frontend, applications mobiles, fichiers source map, documentations internes exposées ou requêtes enregistrées dans les clients.

Tester les contrôles d’accès sur les objets et relations

L’un des tests les plus importants consiste à vérifier que l’accès à chaque objet respecte correctement les permissions de l’utilisateur.

query {
  project(id: "proj-421") {
    id
    name
    description
  }
}

Si l’utilisateur possède légitimement proj-421, le pentester peut tester proj-422. Si ce projet appartient à un autre utilisateur ou à une autre organisation et que l’API retourne les informations, la vulnérabilité est équivalente à une BOLA classique.

GraphQL ajoute cependant une difficulté liée aux relations imbriquées. Un resolver principal peut appliquer correctement ses contrôles, tandis qu’un champ enfant donne accès à un objet qui n’a pas été vérifié avec la même rigueur.

Par exemple, un utilisateur autorisé à consulter un projet ne doit pas nécessairement pouvoir récupérer les propriétés sensibles de son propriétaire :

query {
  organisation(id: "org-51") {
    projects {
      owner {
        id
        email
        apiKeys {
          name
          value
        }
      }
    }
  }
}

Chaque resolver manipulant une donnée sensible doit donc appliquer les règles adaptées au contexte, plutôt que de faire confiance au fait qu’un contrôle a été exécuté plus tôt dans la chaîne de résolution.

Autorisation au niveau des propriétés et mutations

GraphQL facilite la sélection fine des champs retournés. Une interface légitime peut demander :

query {
  currentUser {
    id
    name
    email
  }
}

Le pentester recherche d’autres propriétés exposées par le schéma :

query {
  currentUser {
    id
    name
    email
    role
    internalNotes
    mfaSecret
  }
}

Si l’utilisateur peut récupérer des propriétés sensibles simplement parce qu’elles existent dans le schéma, l’API présente un défaut d’autorisation au niveau des propriétés.

Les mutations doivent faire l’objet du même niveau d’analyse. Une mutation de mise à jour de profil peut accepter un champ role non prévu, ou permettre de cibler l’identifiant d’un autre utilisateur. Les contrôles doivent être appliqués à la mutation, à l’objet concerné et à chaque propriété sensible.

Aliases et batching

GraphQL permet d’exécuter plusieurs fois le même champ sous différents alias dans une seule requête. Prenons une vérification d’OTP :

mutation {
  try1: verifyOtp(code: "000001") { success }
  try2: verifyOtp(code: "000002") { success }
  try3: verifyOtp(code: "000003") { success }
  try4: verifyOtp(code: "000004") { success }
}

Si le système limite uniquement le nombre de requêtes HTTP, il peut considérer cette opération comme une seule tentative alors que plusieurs vérifications sont réellement exécutées.

Certaines implémentations acceptent également plusieurs opérations GraphQL dans une même requête HTTP :

[
  { "query": "mutation { verifyOtp(code:\"000001\") { success } }" },
  { "query": "mutation { verifyOtp(code:\"000002\") { success } }" },
  { "query": "mutation { verifyOtp(code:\"000003\") { success } }" }
]

Le batching peut donc compliquer les mécanismes de rate limiting ou les outils de supervision qui analysent uniquement le nombre de requêtes réseau. Les limites doivent être appliquées au niveau de l’action métier ou du nombre d’opérations réellement exécutées.

Profondeur, complexité et problème N+1

GraphQL permet de construire des requêtes fortement imbriquées. Une seule query peut traverser plusieurs relations et provoquer un volume très important de traitements backend.

query {
  organisation {
    projects {
      members {
        projects {
          members {
            projects {
              members {
                id
              }
            }
          }
        }
      }
    }
  }
}

Le risque ne dépend pas uniquement de la profondeur visuelle. Une query peu profonde peut également être coûteuse si elle récupère des milliers d’objets ou déclenche de nombreux accès à la base de données.

Le problème N+1 constitue un exemple classique. Une query demandant 1 000 projets puis le propriétaire de chaque projet peut provoquer une première requête de récupération des projets puis 1 000 requêtes supplémentaires si les resolvers sont implémentés naïvement.

Les protections peuvent combiner limites de profondeur, limites du nombre d’objets, pagination, timeouts, analyse de complexité et mécanismes de batching et de cache côté serveur.

Fragments, directives et persisted queries

Les fragments permettent de réutiliser des ensembles de champs. Ils ne constituent pas une vulnérabilité en eux-mêmes, mais doivent être correctement pris en compte par les mécanismes de contrôle de complexité et d’autorisation.

Les directives telles que @include et @skip, ainsi que les directives personnalisées, peuvent également influencer le comportement de la requête. Lorsqu’une application utilise une directive interne pour appliquer un contrôle de sécurité ou une transformation, le pentester doit vérifier qu’elle est utilisée de façon cohérente.

Les persisted queries permettent au serveur d’associer une query préenregistrée à un identifiant ou à un hash. Ce mécanisme peut réduire la surface offerte aux requêtes arbitraires lorsqu’il est utilisé comme allowlist stricte, mais cette propriété dépend entièrement de l’implémentation. Le pentester détermine si le serveur accepte également des queries non persistées, s’il permet d’enregistrer dynamiquement de nouvelles queries et si les permissions sont correctement associées à chaque opération persistée.

Subscriptions

Les subscriptions permettent au client de recevoir des mises à jour en temps réel, fréquemment à travers WebSocket. Elles introduisent donc des problématiques supplémentaires.

L’authentification doit être contrôlée lors de l’établissement de la connexion, mais également pendant sa durée de vie. Les permissions doivent aussi être vérifiées sur chaque flux. Un utilisateur appartenant à l’organisation A ne doit pas pouvoir s’abonner aux événements de l’organisation B simplement en modifiant un identifiant.

La révocation des sessions et l’expiration des tokens doivent également être prises en compte sur les connexions longues, afin qu’un token révoqué ne continue pas à donner accès indéfiniment à des événements sensibles.

Spécificités des pentests SOAP

La première étape consiste souvent à analyser le WSDL lorsqu’il est disponible. Celui-ci peut révéler les opérations supportées, les types de messages, les schémas XML et les endpoints utilisés.

Le pentester analyse ensuite les contrôles d’accès, la validation des messages et les mécanismes WS-Security. Une attention particulière doit être portée aux parsers XML, aux signatures et au fait qu’une application peut interpréter le document différemment du mécanisme qui l’a validé.

Les headers SOAP et notamment SOAPAction doivent également être pris en compte, car certains composants peuvent les utiliser pour router ou autoriser les opérations. Une divergence entre la valeur du header et le contenu réel du message peut révéler des incohérences de traitement.

Les erreurs de configuration, les endpoints de test ou de management, les anciennes versions de services et les opérations non documentées constituent enfin des axes de reconnaissance importants dans les environnements SOAP historiques.

Spécificités des pentests gRPC

Lorsqu’un environnement gRPC est identifié, le pentester cherche à déterminer les services et méthodes accessibles. Lorsque gRPC Reflection est activée, cette découverte peut être grandement simplifiée. En son absence, les fichiers .proto, applications clientes, dépôts de code ou informations exposées par les erreurs peuvent fournir des informations utiles.

Les tests portent ensuite sur l’authentification, les metadata gRPC, les contrôles d’accès appliqués à chaque méthode, les messages Protobuf et les différents modes de streaming.

La consommation de ressources constitue également un point important lorsque le service accepte des streams longs, de gros messages ou de nombreuses opérations simultanées. Une protection uniquement appliquée à la connexion initiale peut être insuffisante si le client peut ensuite envoyer un volume important de données ou maintenir durablement des streams coûteux.

API gateways, cloud et microservices

Une API n’existe rarement seule. Dans une architecture moderne, une requête peut traverser une API gateway avant d’être transmise à plusieurs microservices.

Le pentester doit donc comprendre où sont appliqués les différents contrôles. Une gateway peut vérifier le JWT, tandis que le microservice considère ensuite que toute requête reçue est digne de confiance. Cette architecture devient dangereuse si le microservice est également accessible directement depuis un autre réseau ou une autre interface.

La sécurité service-to-service doit donc être analysée au même titre que la sécurité exposée aux utilisateurs. Des mécanismes comme mTLS, les identités de workloads, les IAM cloud et les permissions des services peuvent entrer dans le périmètre lorsqu’ils participent directement au modèle de confiance de l’API.

Les API gateways introduisent également leurs propres risques : routes par défaut trop permissives, différences de normalisation d’URL, authentification appliquée sur certaines routes mais pas sur d’autres, transformations de headers ou de payloads, politiques CORS incohérentes et anciennes routes toujours configurées.

Pentest API en boite noire

Un pentest black box reproduit la situation d’un attaquant externe disposant de très peu d’informations initiales. Le pentester ne reçoit généralement ni documentation API, ni code source, et parfois aucun compte utilisateur.

La découverte de la surface d’attaque prend alors une place particulièrement importante. Il faut identifier les domaines, sous-domaines, gateways, applications web et mobiles ainsi que les routes accessibles publiquement.

Reconnaissance et découverte de l’exposition externe

Les bundles JavaScript peuvent révéler des endpoints. Une application mobile peut permettre de reconstruire les appels backend. Une documentation Swagger oubliée peut exposer des fonctions inconnues. Des environnements de développement ou de staging peuvent également rester accessibles depuis Internet.

Le pentester cherche aussi les technologies backend, frameworks, versions de l’API, méthodes HTTP supportées et mécanismes d’authentification visibles depuis l’extérieur.

Mauvaises configurations et interfaces de debug

Une mauvaise configuration de framework peut considérablement accélérer l’audit. Une application Symfony exécutée avec des mécanismes de debug ou de profiler exposés peut, par exemple, révéler des routes internes, variables d’environnement, informations de configuration, traces et chemins de code.

Ces informations ne constituent pas toujours une compromission immédiate, mais elles peuvent transformer une surface initialement opaque en environnement beaucoup plus documenté et orienter la recherche vers des fonctions sensibles.

Découverte des endpoints cachés

Sans documentation, le pentester doit reconstruire la surface de l’API. Des fichiers tels que /swagger.json ou /openapi.json constituent des sources privilégiées lorsqu’ils sont accessibles.

En leur absence, des outils de découverte peuvent rechercher des routes courantes ou des paramètres non documentés. Les tests doivent rester contrôlés afin de ne pas générer un volume excessif de requêtes sur des environnements de production.

La découverte d’un simple endpoint d’inscription peut parfois modifier considérablement le contexte de l’audit : un compte légitime permet alors d’obtenir un token et d’accéder à l’ensemble des fonctions authentifiées.

Du black box à des conditions proches du grey box

Un phénomène intéressant apparaît fréquemment pendant les pentests black box. L’auditeur commence sans information, mais les données qu’il découvre peuvent progressivement lui apporter un niveau de visibilité beaucoup plus important.

Une documentation OpenAPI, une interface de debug, un portail développeur ou une fuite de configuration peuvent révéler les endpoints, paramètres et workflows. Le système lui-même fournit alors à l’attaquant les informations qu’une entreprise n’aurait normalement communiquées que dans le cadre d’un audit grey box.

C’est pourquoi des problèmes apparemment limités à de la divulgation d’informations peuvent avoir un impact significatif sur la suite d’une attaque.

Pentest API en boite grise

Le pentest grey box fournit au pentester certaines informations ou certains accès. Il peut s’agir d’une documentation Swagger/OpenAPI, de plusieurs comptes correspondant à différents rôles, d’un environnement de test ou d’informations partielles sur l’architecture.

Cette approche permet généralement d’augmenter fortement la couverture. Le pentester peut consacrer moins de temps à reconstruire les éléments déjà documentés et davantage à analyser la logique métier, les contrôles d’accès et les interactions entre utilisateurs.

Elle est particulièrement adaptée aux environnements SaaS multi-tenant, car plusieurs comptes peuvent être utilisés pour vérifier précisément l’isolation entre utilisateurs, rôles et organisations.

Exploiter la documentation et les accès authentifiés

Une spécification OpenAPI permet de comprendre rapidement les endpoints, paramètres, schémas d’objets, méthodes d’authentification et formats de réponse. Elle peut être importée dans des outils comme Burp Suite, Postman ou Insomnia afin de construire une base de travail.

Le pentester peut ensuite comparer les réponses entre plusieurs rôles, modifier les identifiants, tester les propriétés non documentées et analyser les différences entre la documentation et le comportement réel.

Exemple de Mass Assignment en grey box

Considérons une application collaborative permettant de modifier la date d’un rendez-vous :

PATCH /auth/appointment/137 HTTP/1.1
Authorization: Bearer <JWT>
Content-Type: application/json

{
  "date": "09/11/2026"
}

La documentation indique seulement que date est modifiable. L’observation des réponses API ou d’autres endpoints peut toutefois révéler que l’objet possède également une propriété id.

Le pentester peut alors tester :

PATCH /auth/appointment/137 HTTP/1.1
Authorization: Bearer <JWT>
Content-Type: application/json

{
  "id": 136,
  "date": "09/11/2026"
}

Si le backend associe automatiquement toutes les propriétés reçues à l’objet sans définir précisément celles que l’utilisateur a le droit de modifier, l’opération peut agir sur un autre rendez-vous.

Ce scénario illustre l’intérêt du grey box : la documentation facilite l’accès à la fonctionnalité, mais l’exploitation repose ensuite sur une analyse manuelle du modèle de données et du comportement backend.

Exemple de SSRF via une intégration backend

Une API peut permettre de récupérer un document :

GET /auth/document/aef452cf1g15f?location={SOURCE_REPOSITORY_ENDPOINT}/document/aef452cf1g15f HTTP/1.1
Authorization: Bearer <JWT>

Le paramètre location peut initialement sembler être un simple chemin de fichier. En modifiant progressivement cette valeur et en observant les réponses, le pentester peut découvrir que le serveur transmet en réalité ce paramètre à un service backend.

Une tentative de traversal peut par exemple provoquer une réponse inattendue :

GET /auth/document/aef452cf1g15f?location=../../ HTTP/1.1
Authorization: Bearer <JWT>

Réponse :

{
  "couchdb": "Welcome",
  "version": "3.1.1"
}

Cette réponse indique que l’API peut interagir directement avec une instance CouchDB interne inaccessible depuis Internet. L’API devient alors un intermédiaire permettant d’atteindre le backend.

Le pentester cherche ensuite, dans le cadre autorisé, à déterminer quelles opérations sont accessibles. Une route comme _all_docs?include_docs=true peut par exemple révéler que la SSRF permet de lire des documents stockés dans la base.

Contrôles d’accès GraphQL en grey box

L’accès authentifié à une API GraphQL permet souvent de comprendre plus rapidement les objets et relations. Dans un environnement multi-tenant, le pentester peut comparer les résultats de queries similaires avec deux comptes appartenant à des organisations différentes.

Une vulnérabilité peut apparaître si l’API vérifie correctement le tenant sur l’objet principal mais oublie cette relation sur un objet imbriqué ou une mutation. L’analyse manuelle des resolvers et des relations devient alors essentielle pour identifier les chemins de fuite cross-tenant.

Avantages et limites du grey box

Le grey box offre un excellent compromis entre réalisme et profondeur. Il permet une meilleure couverture des fonctions authentifiées, une analyse plus poussée de la logique métier et des contrôles d’accès, tout en conservant une perspective d’attaquant disposant de droits limités.

Sa principale limite est qu’une partie du temps consacré à la découverte externe disparaît. Un audit strictement centré sur la documentation fournie peut donc manquer une ancienne API ou un service internet-facing oublié. Pour les environnements sensibles, combiner une phase de reconnaissance externe avec des conditions grey box offre souvent une couverture plus complète.

Pentest API en boite blanche

Le pentest white box donne accès au code source et, selon le périmètre, à la documentation technique, à l’architecture ou à certaines configurations.

Cette visibilité ne remplace pas les tests dynamiques. Elle permet au contraire de les orienter plus efficacement et d’identifier des incohérences difficilement visibles depuis l’extérieur.

Analyser l’implémentation des contrôles d’accès

Dans une application contenant plusieurs centaines de routes, le pentester peut rechercher les mécanismes de permission utilisés puis comparer systématiquement leur utilisation.

Prenons une application utilisant deux guards : Admin et AdminForOrganisation.

Une route sensible peut être protégée ainsi :

@Get('/organisation/:organisationId')
@UseGuards(Admin)
@UseGuards(AdminForOrganisation)

Le premier contrôle vérifie que l’utilisateur possède un rôle administrateur. Le second vérifie qu’il possède ce rôle dans l’organisation concernée.

Le pentester peut alors rechercher les routes utilisant seulement @UseGuards(Admin) et découvrir :

@Get('/organisation/:organisationId/api-settings')
@UseGuards(Admin)

Si aucun contrôle équivalent à AdminForOrganisation n’est réalisé ailleurs, un administrateur de l’organisation A peut potentiellement modifier organisationId et accéder aux paramètres API de l’organisation B.

L’intérêt du white box ne réside donc pas uniquement dans la recherche de fonctions dangereuses. Il permet d’étudier systématiquement les hypothèses de sécurité faites par les développeurs et de repérer les exceptions dans un modèle qui semble cohérent au premier regard.

Recherche des sources, traitements et sinks

L’accès au code permet de suivre le parcours d’une donnée. Le pentester cherche où les données contrôlées par l’utilisateur entrent dans l’application, quels traitements elles subissent puis dans quel contexte elles sont utilisées.

Une même entrée peut être sûre lorsqu’elle est enregistrée dans une base mais dangereuse lorsqu’elle est ensuite insérée dans une commande système, une requête SQL ou un template. Cette analyse est particulièrement efficace pour rechercher des vulnérabilités de second ordre ou des chemins d’exploitation difficiles à identifier uniquement depuis l’extérieur.

DTO, modèles et validation des propriétés

Les frameworks modernes utilisent souvent des DTO, modèles de validation ou mécanismes d’autobinding. Le white box permet de vérifier si les propriétés acceptées sont explicitement définies ou si l’intégralité d’un objet backend peut être alimentée à partir du payload utilisateur.

Cette analyse est particulièrement pertinente pour détecter les BOPLA et Mass Assignment. Elle permet aussi d’identifier les différences entre plusieurs routes qui manipulent le même objet mais appliquent des DTO ou des validateurs différents.

Clients HTTP et recherche de SSRF

Lorsqu’une fonctionnalité effectue une requête HTTP côté serveur, le code permet d’identifier immédiatement le client utilisé et les protections appliquées. Le pentester peut vérifier comment les redirections sont gérées, quels protocoles sont autorisés, comment les adresses IP sont validées et si une nouvelle résolution DNS peut intervenir après une première vérification.

Cette visibilité permet d’aller beaucoup plus loin que la simple recherche de paramètres ressemblant à une URL, notamment pour analyser les protections contre les adresses privées, le DNS rebinding, les redirections successives ou les différences entre validation et connexion effective.

Secrets, configuration et confiance inter-services

L’accès au code peut révéler des secrets hardcodés, d’anciennes clés, des endpoints internes ou des configurations dangereuses. La présence d’un secret dans un dépôt ne suffit toutefois pas à déterminer sa gravité : il faut vérifier s’il est toujours valide, quelles permissions il possède et dans quel environnement il peut être utilisé.

Le white box permet également de comprendre les mécanismes de confiance entre microservices. Un service peut accepter aveuglément un header ajouté par une gateway, sans vérifier qu’il ne peut pas être fourni par un autre chemin réseau.

Exemple d’injection de code détectée en white box

Considérons une API intégrée à une plateforme comptable qui permet de soumettre des formules mathématiques évaluées côté serveur :

calculate(formula) {
  try {
    return eval(`(function() { return ${formula}; }())`);
  } catch (e) {
    return null;
  }
}

La variable formula est entièrement contrôlée par l’utilisateur et injectée dans eval() sans validation adaptée. Un attaquant peut donc injecter du JavaScript arbitraire. Dans un environnement Node.js, cette injection de code peut ensuite permettre d’appeler des modules sensibles et aboutir à une exécution de commandes système.

L’analyse white box identifie rapidement la cause racine, alors qu’un test externe pourrait nécessiter de nombreuses hypothèses avant de comprendre que la formule est exécutée dynamiquement.

Avantages et limites du white box

Le white box offre le niveau de visibilité et de profondeur le plus élevé. Il est particulièrement adapté aux grandes applications, aux modèles de permissions complexes, aux architectures multi-tenant et aux environnements contenant de nombreux microservices.

Il peut cependant demander davantage de temps lorsque le codebase est important ou hétérogène. Par ailleurs, l’accès à l’implémentation peut réduire la part de découverte purement externe. Il est donc souvent pertinent de conserver une phase dynamique proche du black ou grey box afin de confronter le code au comportement réellement exposé.

Combien coûte un pentest API ?

Le coût est directement lié à la charge nécessaire pour couvrir correctement le périmètre. Les principaux facteurs sont la taille de l’API, la complexité métier, le nombre de profils utilisateurs, l’approche black box, grey box ou white box, les technologies présentes et le niveau de profondeur attendu.

Une estimation sérieuse nécessite généralement un échange préalable ainsi que l’analyse de la documentation disponible. Un prix extrêmement faible obtenu sans compréhension du périmètre peut signifier que le temps consacré aux tests sera insuffisant pour analyser correctement les contrôles d’accès et la logique métier.

Or ce sont précisément ces domaines qui nécessitent le plus de travail manuel et qui concentrent une grande partie des vulnérabilités à fort impact dans les API modernes.

Comment choisir un prestataire pour un pentest API ?

Un pentest API ne doit pas être réduit à l’exécution d’un scanner. Le prestataire doit être capable d’expliquer sa méthodologie, la part de tests manuels, la manière dont il analyse les contrôles d’accès et la logique métier ainsi que les compétences techniques des auditeurs.

L’expérience sur les technologies utilisées est également importante. Une API REST, une API GraphQL complexe, un environnement SOAP historique ou une architecture gRPC ne se testent pas exactement de la même manière.

La qualité du rapport constitue un autre critère déterminant. Une liste de vulnérabilités accompagnée de scores ne suffit pas. Les équipes doivent disposer d’informations permettant de comprendre le scénario, de reproduire le problème et d’implémenter une correction adaptée à l’architecture réelle.

La possibilité de réaliser des contre-tests après remédiation est également importante pour vérifier que les corrections traitent réellement la cause du problème.

Conclusion

La sécurité d’une API ne peut pas être évaluée uniquement en recherchant des injections ou en exécutant un scanner automatisé. Les vulnérabilités les plus importantes sont souvent liées aux relations entre objets, aux permissions, aux propriétés exposées, aux workflows métier et aux interactions entre plusieurs composants.

Un pentest API efficace commence donc par la compréhension de l’application. Le pentester cartographie les ressources, utilisateurs, rôles et processus, puis confronte ces règles à des scénarios d’attaque réalistes.

Cette approche permet de découvrir aussi bien des vulnérabilités techniques classiques que des erreurs beaucoup plus contextuelles : accès cross-tenant, modification de propriétés sensibles, contournement de workflows, abus de fonctions métier, race conditions, consommation excessive de ressources ou détournement d’intégrations backend.

Les approches black box, grey box et white box répondent chacune à des objectifs différents. La première mesure ce qu’un attaquant externe peut découvrir seul, la deuxième améliore considérablement la couverture des fonctions authentifiées et la troisième permet d’analyser directement les mécanismes internes afin d’identifier des incohérences difficilement visibles depuis l’extérieur.

Plus les API deviennent centrales dans les architectures web, mobiles, cloud et microservices, plus leur sécurité dépend de cette capacité à raisonner au-delà de l’endpoint isolé et à considérer l’ensemble du système, de ses données et de sa logique métier.