Tests d'intrusion · Applications web
Applications web
Test d'intrusion d'application web selon l'OWASP WSTG v4.2 : authentification, droits d'accès, logique métier et API. Rapport avec preuves, CVSS et retest.
Tests d'intrusion · 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
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
L'édition actuelle de la liste des risques les plus graves pour les API, et la manière dont nous testons chacun d'eux.
| 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
Chaque style d'API a ses failles typiques. Nous adaptons le périmètre du test à la technologie.
| 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é
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 :
redirect_uri, paramètre state, PKCE (obligatoire pour les clients publics selon la RFC 9700), portées (scopes),kid, contrôle de exp et aud,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
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 :
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
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.
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.
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.
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.
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.
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).
Tests d'intrusion · Applications web
Test d'intrusion d'application web selon l'OWASP WSTG v4.2 : authentification, droits d'accès, logique métier et API. Rapport avec preuves, CVSS et retest.
Logiciel sur mesure · Intégration
Intégration ERP et intégration de systèmes : ERP, CRM, MES et WMS reliés par API, files de messages ou ETL. Sécurité selon l'OWASP API Top 10 et supervision.
Tests d'intrusion · Tarifs
Quel est le prix d'un pentest ? Ce qui détermine le coût d'un test d'intrusion, nos offres, la checklist de demande et les pièges de l'offre la moins chère.
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