Tests d'intrusion · API
API
Pentest API selon l'OWASP API Security Top 10 2023 : autorisation au niveau des objets, OAuth 2.0, JWT, GraphQL et webhooks. Rapport avec preuves et retest.
Tests d'intrusion · Applications web
Test d'intrusion d'applications web
Un test d'intrusion d'application web montre si un attaquant peut prendre le contrôle d'un compte, lire les données d'autres utilisateurs ou contourner les règles métier de votre système. Nous testons portails clients, systèmes transactionnels, interfaces d'administration et boutiques en ligne selon l'OWASP WSTG v4.2 - manuellement, avec preuves à l'appui et retest (contre-test) après correction.
01Quand
Quand commander un test d'application web
- avant d'ouvrir l'application à vos clients - nouveau portail, système transactionnel, espace partenaire,
- après un changement important - nouveau module de paiement, refonte du modèle de rôles, intégration avec un prestataire externe, réécriture du frontend,
- de façon récurrente - pour les systèmes qui traitent des données personnelles ou financières, généralement une fois par an et après chaque changement significatif,
- à la demande d'un client ou d'un régulateur - avant la signature d'un contrat avec un grand groupe, dans le cadre de DORA ou de NIS2/KSC,
- après un incident - pour vérifier que la faille a bien été corrigée et qu'il n'en existe pas d'autres du même type.
Nous testons les applications quelle que soit leur technologie : applications classiques rendues côté serveur (Java, .NET, PHP, Python, Node.js), SPA avec backend API, systèmes bâtis sur des plateformes CMS et e-commerce.
L'approche la plus souvent retenue est la boîte grise - un test avec des comptes de test pour chaque rôle. C'est elle qui donne le plus de résultats au regard du temps investi, car elle permet de vérifier l'essentiel d'une application métier : les droits d'accès et la logique des processus. Vous trouverez une comparaison des approches sur notre page test d'intrusion.
02Périmètre
Périmètre : test d'intrusion d'application web selon l'OWASP WSTG
Dans l'Audit complet, nous réalisons au moins 67 tests répartis dans les 12 catégories de l'OWASP WSTG v4.2. Voici ce que nous vérifions dans chacune d'elles.
| Catégorie WSTG | Ce que nous vérifions |
|---|---|
| Collecte d'informations (INFO) | Technologies et versions, points d'entrée, cartographie de l'application, informations divulguées dans le code des pages, les commentaires et les fichiers. |
| Configuration et déploiement (CONF) | Configuration du serveur et de TLS, en-têtes de sécurité, méthodes HTTP, copies de sauvegarde de fichiers, interfaces d'administration, ressources cloud. |
| Gestion des identités (IDNT) | Rôles et leur définition, inscription et création de comptes, possibilité d'énumérer les utilisateurs. |
| Authentification (ATHN) | Connexion, MFA, réinitialisation du mot de passe, verrouillage du compte, fonction « se souvenir de moi », transmission des identifiants. |
| Autorisation (ATHZ) | IDOR, élévation de privilèges horizontale et verticale, contournement du schéma d'autorisation, path traversal, OAuth. |
| Gestion des sessions (SESS) | Jetons de session et JWT, attributs des cookies, fixation de session, CSRF, déconnexion et expiration des sessions. |
| Validation des entrées (INPV) | Injection SQL, XSS, XXE, SSTI, SSRF, injection de commandes système, HTTP request smuggling. |
| Gestion des erreurs (ERRH) | Messages d'erreur et traces d'exécution (stack traces) qui révèlent la structure du système ou des données. |
| Cryptographie (CRYP) | Suites de chiffrement TLS faibles, padding oracle, données sensibles transmises sur des canaux non chiffrés, algorithmes faibles. |
| Logique métier (BUSL) | Contournement d'étapes d'un processus, limites et quantités, manipulation des prix, situations de concurrence (race conditions), envoi de fichiers. |
| Tests côté client (CLNT) | DOM XSS, clickjacking, CORS, communication entre fenêtres, données stockées dans le navigateur. |
| API (APIT) | Interfaces appelées par l'application, y compris GraphQL. Le test complet d'une API publique ou partenaire est un service distinct. |
03Risques
Les vulnérabilités les plus fréquentes des applications web - OWASP Top 10:2025
L'édition 2025 de l'OWASP Top 10 classe les risques les plus graves pour les applications web. Voici à quoi ils ressemblent en pratique.
| Catégorie | À quoi cela ressemble en pratique |
|---|---|
| A01 Broken Access Control | Modifier un numéro dans l'URL affiche la facture d'un autre client (IDOR) ; un simple utilisateur appelle une fonction d'administration. Depuis l'édition 2025, la catégorie couvre aussi la SSRF. |
| A02 Security Misconfiguration | Mode débogage activé, comptes par défaut, politique CORS trop permissive, sauvegardes accessibles publiquement. |
| A03 Software Supply Chain Failures | Bibliothèques présentant des vulnérabilités connues, dépendances non vérifiées, paquets compromis dans la chaîne de build. |
| A04 Cryptographic Failures | Données sensibles non chiffrées, mots de passe hachés avec un algorithme rapide, versions de TLS obsolètes. |
| A05 Injection | Injection SQL dans le moteur de recherche, XSS dans un champ de commentaire, injection de commandes via un nom de fichier. |
| A06 Insecure Design | Aucune limite de tentatives pour les codes promo, étape de vérification d'un processus qu'il est possible de sauter. |
| A07 Authentication Failures | Aucune protection contre le credential stuffing, lien de réinitialisation du mot de passe prévisible, MFA contournable. |
| A08 Software or Data Integrity Failures | Désérialisation de données sans vérification, mises à jour non signées, pipeline CI/CD sans contrôle d'intégrité. |
| A09 Security Logging and Alerting Failures | Aucune journalisation des échecs de connexion ni des modifications de droits, aucune alerte en cas d'activité suspecte. |
| A10 Mishandling of Exceptional Conditions | Une erreur de gestion d'exception divulgue des données ou laisse passer une requête qui aurait dû être rejetée. |
Le Top 10 est un minimum, pas le périmètre d'un test. Dans les applications métier, les constats les plus graves combinent généralement plusieurs catégories : une IDOR qui permet de lire les données d'autres clients, une élévation de privilèges par l'appel d'une fonction d'administration depuis un compte ordinaire, une injection SQL dans un filtre de rapport rarement utilisé, une XSS dans un champ visible par l'administrateur (détournement de sa session), une SSRF dans une fonction d'import depuis une URL qui ouvre l'accès au réseau interne ou aux métadonnées du cloud, ainsi que des failles de logique - quantité négative de produits dans le panier, double utilisation d'un code à usage unique ou validation de sa propre demande.
04Architecture
Applications SPA, backend et API
Les applications modernes (React, Angular, Vue) s'exécutent dans le navigateur et récupèrent leurs données auprès d'une API. Tout ce qui se trouve dans le navigateur peut être consulté et modifié par l'utilisateur - c'est pourquoi chaque décision relative aux droits d'accès doit être prise côté serveur.
Dans ce type d'application, nous vérifions en particulier : les requêtes envoyées à l'API en contournant l'interface, les endpoints que l'interface n'utilise pas (anciennes versions, fonctions de test), le stockage des jetons dans le navigateur, la configuration CORS, les requêtes GraphQL et l'introspection du schéma.
Si l'API sert également des applications mobiles ou des partenaires, mieux vaut la tester séparément, endpoint par endpoint - voir notre pentest API. Si vous pouvez nous donner accès au code du backend, le test peut être complété par un audit de code source : nous trouvons alors aussi les vulnérabilités dans les chemins inaccessibles depuis l'extérieur.
05Préparation
Environnement, comptes et rôles
Environnement de test ou production
Un test en boîte grise se déroule idéalement dans un environnement de test qui reproduit la production : même version de l'application et même configuration, mais avec des données fictives. Nous pouvons alors vérifier les fonctions qui modifient les données (par exemple la passation de commandes) sans risque pour vos clients.
En production, nous testons en mode non intrusif, dans des plages horaires convenues - sans modification des données ni tests de charge. Le test depuis l'extérieur (boîte noire) est généralement réalisé en production, car ce qui compte, c'est ce que voit l'attaquant.
Comptes et rôles
Nous avons besoin de comptes pour chaque rôle du système - idéalement deux par rôle, afin de vérifier qu'un utilisateur ne peut pas accéder aux données d'un autre. Une courte description des rôles et des droits est également utile : qui peut valider, exporter, gérer les utilisateurs.
Le nombre de rôles et de fonctions est le principal facteur qui détermine la durée et le prix du test - nous le détaillons sur notre page tarifs des tests d'intrusion.
06Extrait de rapport
Comment nous décrivons une vulnérabilité dans le rapport
Chaque constat comprend une preuve, un score CVSS, le contexte métier et une recommandation. En voici un exemple, avec des données de démonstration.
WEB-02
Lecture des factures d'autres clients par modification de l'identifiant (IDOR)
Medium CVSS 3.1 6.5
Description
Un client connecté peut télécharger n'importe quelle facture en modifiant son numéro dans l'URL de la requête. Le serveur vérifie que l'utilisateur est connecté, mais pas que la facture lui appartient. Dans l'évaluation contextuelle, nous relevons le risque à High : les factures contiennent les données personnelles et les montants des transactions d'autres clients.
Preuve
$ curl -s -H "Authorization: Bearer [jeton du client A]" \
https://app.entreprise.example/api/invoices/10482
HTTP/1.1 200 OK
{"id":10482,"customer":"Client B","total":"12300.00","currency":"PLN"}Recommandation
À chaque requête, vérifiez côté serveur que la ressource appartient à l'utilisateur connecté (par exemple au moyen d'une condition sur l'identifiant client dans la requête à la base de données), au lieu de compter sur la difficulté à deviner le numéro. Ajoutez des tests d'autorisation automatisés pour chaque rôle afin que l'erreur ne réapparaisse pas lors d'une prochaine modification.
07Sites et boutiques
Audit de sécurité d'un site web
Tous les sites n'ont pas besoin d'un test applicatif complet. Pour un site d'entreprise sans comptes utilisateurs - y compris sous WordPress ou un autre CMS - un test depuis l'extérieur (l'Audit externe) suffit généralement. Il couvre :
- la configuration du serveur, TLS et les en-têtes de sécurité,
- les versions du CMS, des thèmes et des extensions présentant des vulnérabilités connues,
- l'accessibilité des interfaces d'administration et des fichiers qui ne devraient pas être publics,
- les formulaires de contact et le moteur de recherche (injections, XSS, envois abusifs).
Une boutique en ligne ou un service avec comptes clients est déjà une application métier : panier, paiements, remises, historique des commandes et données personnelles. Il faut alors un test avec un utilisateur connecté (boîte grise), car les failles les plus dangereuses - accès aux commandes d'autres clients, manipulation des prix, abus des codes promo - n'apparaissent qu'après connexion.
Nous comparons les offres et leur périmètre sur notre page test d'intrusion.
08Durée et prix
Combien de temps dure et combien coûte un test d'application web ?
La durée et le prix du test dépendent avant tout du nombre de rôles et de fonctions (écrans, formulaires, processus), du nombre d'endpoints d'API, des intégrations avec d'autres systèmes, de l'approche (boîte noire, grise ou blanche) et de la présence d'un retest dans le contrat. Nous n'annonçons pas de prix à l'avance, car deux applications au nom similaire peuvent avoir des périmètres sans commune mesure. Nous préparons une proposition avec calendrier après un court échange de cadrage et répondons aux demandes sous 24 heures les jours ouvrés. Vous trouverez les détails et la checklist de demande sur notre page tarifs des tests d'intrusion.
Questions fréquentes
Un scanner automatique d'applications web suffit-il ?
Un scanner est un bon complément, mais il ne remplace pas un test. Il détecte une partie des erreurs de configuration connues et les cas d'injection simples, mais il ne comprend pas les règles de votre activité : il ne vérifiera pas si le client A peut consulter la facture du client B ou sauter l'étape de paiement. Ces failles d'autorisation et de logique sont les constats graves les plus fréquents lors des tests manuels.
Testez-vous les applications SPA (React, Angular, Vue) ?
Oui. Dans une SPA, la logique de sécurité doit s'exécuter côté serveur : nous testons donc avant tout l'API utilisée par le frontend, mais aussi ce que l'application stocke dans le navigateur, la configuration CORS et la gestion des jetons. Masquer des boutons dans l'interface ne constitue pas une protection - nous vérifions ce qui se passe lorsqu'une requête est envoyée en contournant l'interface.
De combien de comptes de test avez-vous besoin ?
Idéalement, de deux comptes par rôle (par exemple deux clients, deux collaborateurs, un administrateur). Deux comptes du même rôle permettent de vérifier qu'un utilisateur n'a pas accès aux données de l'autre - c'est la vulnérabilité IDOR classique. Les comptes doivent contenir des données fictives, et non celles de vrais clients.
Le test couvre-t-il l'API utilisée par l'application ?
Oui, l'API appelée par l'application est testée dans le cadre du test de l'application web. Si l'API est également mise à disposition de partenaires ou d'applications mobiles et propose des fonctions que le frontend n'utilise pas, il est judicieux de commander un pentest API distinct : nous vérifions alors chaque endpoint de la spécification.
Pouvez-vous tester un site d'entreprise sous WordPress ou une boutique en ligne ?
Oui. Pour un site d'entreprise sans comptes utilisateurs, un test depuis l'extérieur (boîte noire) suffit généralement : il couvre la configuration du serveur, les versions du CMS et des extensions présentant des vulnérabilités connues, les interfaces d'administration, les formulaires et les fichiers accessibles publiquement. Une boutique avec comptes clients et paiements nécessite en plus un test avec un utilisateur connecté (boîte grise).
Faut-il désactiver le WAF pendant le test ?
Nous recommandons d'ajouter les adresses IP des testeurs aux exceptions du WAF. Nous testons alors l'application elle-même - un WAF peut être contourné, et la vulnérabilité qu'il masque existe toujours. Si vous souhaitez savoir ce que votre WAF bloque réellement, nous pouvons en outre réaliser une partie des tests avec la protection activée et décrire la différence dans le rapport.
Sources
Services associés
Tests d'intrusion · Boîte blanche
Audit de code source (boîte blanche)
Audit de code source et test en boîte blanche : logique d'autorisation, secrets, cryptographie, dépendances avec CVE. Revue manuelle, SAST, SCA et correctifs.
Tests d'intrusion · Tarifs
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.