Tests d'intrusion · API

Pentest API : test d'intrusion de vos API

Un pentest API vérifie que l'interface utilisée par vos applications mobiles, votre frontend et vos partenaires ne donne à personne un accès indu à des données ou à des fonctions. Nous testons les API REST, GraphQL et gRPC ainsi que les webhooks selon l'OWASP API Security Top 10 2023 - endpoint par endpoint, pour chaque rôle.

01Pourquoi un test distinct

Pourquoi le pentest API est un service à part

Une API donne un accès direct aux données et aux fonctions du système - sans interface qui masque les boutons et indique ce qui est permis. Toute personne disposant d'un jeton peut envoyer n'importe quelle requête : modifier un identifiant, ajouter un champ, appeler une méthode que l'application n'utilise jamais.

C'est pourquoi les failles les plus graves des API sont des failles d'autorisation : le serveur vérifie que l'utilisateur est connecté, mais pas qu'il a le droit d'accéder à cet objet, à ce champ ou à cette fonction précise. Un scanner ne détectera pas ce type d'erreur, car il ne connaît pas les règles de votre activité.

02Périmètre

OWASP API Security Top 10 2023 : ce que nous vérifions

L'édition actuelle de la liste des risques les plus graves pour les API, et la manière dont nous testons chacun d'eux.

OWASP API Security Top 10 2023 - risques et méthode de test
Risque En quoi il consiste Comment nous testons
API1 Broken Object Level Authorization (BOLA) Accès à l'objet d'un autre utilisateur en remplaçant l'identifiant dans la requête. Nous appelons chaque endpoint comportant un identifiant depuis les comptes de différents utilisateurs et rôles.
API2 Broken Authentication Connexion faible, jetons acceptés sans vérification de leur signature ou de leur validité. Connexion, renouvellement et révocation des jetons, JWT, limites de tentatives.
API3 Broken Object Property Level Authorization L'API renvoie ou permet de modifier des champs qui devraient être inaccessibles. Nous comparons les réponses aux besoins réels du client et tentons de définir des champs tels que rôle, statut ou solde.
API4 Unrestricted Resource Consumption Absence de limites sur le nombre de requêtes, la taille des données et la pagination. Nous vérifions les limites par des requêtes individuelles - sans test DoS.
API5 Broken Function Level Authorization (BFLA) Un simple utilisateur appelle une fonction d'administration. Endpoints d'administration appelés depuis des comptes aux droits inférieurs, changement de méthode HTTP.
API6 Unrestricted Access to Sensitive Business Flows Automatisation d'un flux métier, par exemple réservations en masse ou achat massif d'offres promotionnelles. Analyse des flux exposés aux abus et des protections contre l'automatisation.
API7 Server Side Request Forgery (SSRF) L'API récupère une ressource à partir d'une adresse fournie par l'utilisateur. Paramètres contenant des URL, webhooks et imports - accès au réseau interne et aux métadonnées du cloud.
API8 Security Misconfiguration Erreurs de configuration : CORS, en-têtes, messages d'erreur, méthodes superflues. Revue de la configuration de la passerelle et du serveur, ainsi que des réponses en situation d'erreur.
API9 Improper Inventory Management Anciennes versions de l'API et environnements de test accessibles depuis Internet. Comparaison de la spécification avec ce qui répond réellement, recherche de versions parallèles.
API10 Unsafe Consumption of APIs Confiance aveugle dans les données provenant d'API de prestataires externes. Validation des données issues des intégrations, gestion des redirections et des erreurs du prestataire.

03Technologies

REST, GraphQL, gRPC et webhooks

Chaque style d'API a ses failles typiques. Nous adaptons le périmètre du test à la technologie.

Technologies d'API et points d'attention des tests
Technologie Ce sur quoi nous portons une attention particulière
REST Autorisation au niveau des objets et des fonctions, méthodes HTTP, versions parallèles de l'API, filtres, tri et pagination.
GraphQL Introspection, autorisation des champs, requêtes imbriquées et groupées, alias qui contournent les limites, messages d'erreur trop détaillés.
gRPC Réflexion du serveur, authentification dans les métadonnées, validation des messages, méthodes accessibles sans autorisation.
Webhooks Vérification de la signature, protection contre le rejeu des messages, SSRF lors de l'enregistrement de l'adresse, données sensibles dans le contenu.

04Identité

OAuth 2.0, OpenID Connect et JWT

Les failles d'authentification des API sont rarement visibles au premier coup d'œil : la connexion fonctionne, et le problème n'apparaît qu'avec une requête inhabituelle. Nous vérifions notamment :

  • les flux OAuth 2.0 - validation de redirect_uri, paramètre state, PKCE (obligatoire pour les clients publics selon la RFC 9700), portées (scopes),
  • les jetons JWT - algorithme et vérification de la signature, robustesse de la clé HMAC, en-tête kid, contrôle de exp et aud,
  • le cycle de vie des jetons - durée de validité, renouvellement, révocation après déconnexion et changement de mot de passe.

Nous évaluons séparément les clés d'API et la communication entre systèmes : nous vérifions que les clés ne se retrouvent pas dans des URL, des journaux ou des fichiers d'applications mobiles, qu'elles n'ont que les droits nécessaires et qu'elles peuvent être remplacées rapidement. Pour les intégrations à risque élevé, nous contrôlons aussi l'authentification TLS mutuelle (mTLS).

Nous testons les mêmes mécanismes dans les applications web - voir notre test d'intrusion d'applications web.

05Intégrations

Intégrations B2B et API partenaires

Les API mises à la disposition de partenaires, de grands comptes et d'autres systèmes de l'entreprise présentent des risques qui leur sont propres. Nous rencontrons le plus souvent :

  • des clés partenaires aux accès trop larges - une seule clé voit les données de tous les clients au lieu d'un seul,
  • une séparation insuffisante des clients dans les systèmes multi-tenant - les données d'une organisation deviennent accessibles à une autre après modification d'un identifiant,
  • l'absence de limites par partenaire - une seule intégration peut bloquer le service pour tous les autres,
  • les formats d'échange de données - XML avec entités externes (XXE), fichiers volumineux sans limites, absence de validation du schéma.

En tant que société de développement logiciel, nous construisons nous-mêmes des API pour des applications web et mobiles : nous savons où se prennent les raccourcis en pratique - et comment les corriger sans réécrire la moitié du système. Pour en savoir plus sur cette partie de notre activité : intégration de systèmes.

06Préparation

Ce dont nous avons besoin pour un test d'API

  • une spécification OpenAPI (Swagger), un schéma GraphQL ou les fichiers proto pour gRPC,
  • des exemples de requêtes, par exemple une collection Postman,
  • des comptes ou des jetons pour chaque rôle - idéalement deux par rôle - ainsi que des clés partenaires de test,
  • un environnement de test avec des données fictives, ou votre accord pour un test non intrusif en production,
  • des informations sur la passerelle d'API, les limites de requêtes et le WAF,
  • un contact technique pendant toute la durée du test.

Plus la documentation est complète, plus nous consacrons de temps aux tests plutôt qu'à la découverte de l'interface. Le nombre d'endpoints et de rôles constitue le principal facteur de prix - détails sur notre page tarifs des tests d'intrusion. Nous commençons le test après l'autorisation écrite du propriétaire du système et l'accord sur les plages horaires, comme dans toute mission décrite sur notre page test d'intrusion.

Questions fréquentes

En quoi un test d'API diffère-t-il d'un test d'application web ?

Le test d'une application web couvre l'API dans la mesure où l'interface l'utilise. Le test d'API va plus loin : nous vérifions chaque endpoint de la spécification, chaque méthode et chaque rôle - y compris les fonctions qu'aucun écran n'appelle, les anciennes versions de l'interface et les accès partenaires. Si l'API ne sert qu'une seule application web, un test d'intrusion d'application web suffit généralement.

Pouvez-vous tester une API sans documentation ?

Oui - nous identifions les endpoints à partir du trafic de l'application, des fichiers JavaScript et des chemins courants. Un tel test est cependant moins complet et plus long, car une partie du temps est consacrée à la découverte de l'interface. Une spécification OpenAPI, un schéma GraphQL ou une collection de requêtes d'exemple permettent de vérifier tout ce que l'API expose.

Un test d'API peut-il être réalisé en production ?

Oui, en mode non intrusif - sans modification des données et sans tests de charge. Les opérations qui créent ou modifient des données (commandes, virements, changements de droits) sont de préférence testées dans un environnement de test avec des données fictives.

Testez-vous GraphQL ?

Oui. Pour GraphQL, nous vérifions notamment l'introspection du schéma, l'autorisation au niveau de chaque champ, les requêtes imbriquées et groupées (batching), les alias qui permettent de contourner les limites de tentatives, et nous contrôlons que les messages d'erreur ne révèlent pas les noms des champs et des types.

Le test couvre-t-il les API des prestataires externes avec lesquels nous sommes intégrés ?

Nous ne pouvons tester les systèmes d'une autre entreprise qu'avec son accord écrit. Sans cet accord, nous testons votre côté de l'intégration : nous vérifions si votre système contrôle correctement les données et les réponses du prestataire, comment il stocke les clés et ce qui se passe lorsque le prestataire répond de manière inattendue (catégorie API10 de l'OWASP API Security Top 10).

Sources

  1. OWASP API Security Top 10 2023 ()
  2. OWASP Web Security Testing Guide (WSTG) v4.2 ()
  3. RFC 9700 - Best Current Practice for OAuth 2.0 Security (janvier 2025) ()
  4. RFC 8725 - JSON Web Token Best Current Practices ()

Mis à jour le

Services associés

Parlons de votre projet ou de votre audit

Décrivez brièvement votre besoin - nous reviendrons vers vous avec une proposition de prochaines étapes. Nous échangeons avec vous en anglais ou en polonais.

ou appelez le +48 575 621 877