Un test d’intrusion d’application web est une attaque simulée, autorisée par écrit, menée par des spécialistes pour découvrir les failles réellement exploitables avant qu’un attaquant ne le fasse. Il se réalise idéalement avant la première mise en production, après chaque évolution majeure et à intervalle régulier pour les applications exposées sur Internet. Pour une application métier, le format le plus utile est souvent le test en « boîte grise », avec un compte de test par rôle, suivi d’un rapport priorisé, des corrections et d’un contre-test.
C’est aussi un exercice souvent mal préparé : périmètre flou, environnement indisponible, comptes de test oubliés, rapport rangé dans un tiroir. Voici comment en tirer le maximum.
Qu’est-ce qu’un test d’intrusion, et que n’est-il pas ?
Un test d’intrusion (pentest en anglais) consiste à se mettre dans la peau d’un attaquant pour tenter de contourner les protections d’une application : accéder aux données d’un autre client, obtenir des droits d’administrateur, injecter des commandes, détourner un parcours de paiement ou de validation. L’auditeur ne se contente pas de repérer une faiblesse : il démontre qu’elle est exploitable et mesure ses conséquences.
Il se distingue de plusieurs exercices voisins, qui se complètent :
| Exercice | Qui le mène | Ce qu’il trouve | Limite |
|---|---|---|---|
| Scan de vulnérabilités | Un outil automatique | Composants obsolètes, failles connues, erreurs de configuration | Ne comprend pas la logique métier, nombreux faux positifs |
| Test d’intrusion | Des auditeurs spécialisés | Failles exploitables, enchaînements, contournement des droits | Photographie à un instant donné, sur un périmètre limité |
| Audit de code source | Des auditeurs qui lisent le code | Failles de logique, erreurs de contrôle d’accès, secrets dans le code | Demande l’accès au code et du temps |
| Audit de configuration | Des auditeurs système | Serveurs, bases, cloud mal paramétrés | Ne teste pas l’application elle-même |
| Programme de bug bounty | Des chercheurs externes rémunérés au résultat | Failles variées, en continu | Adapté aux produits matures et très exposés |
Le guide de test de l’OWASP note que l’analyse du code source est la technique de choix pour trouver des problèmes comme les erreurs de logique métier et de contrôle d’accès. Pour une application à forts enjeux, combiner un test d’intrusion et une revue ciblée du code est souvent le plus efficace. Les grandes familles de failles recherchées sont présentées dans notre article sur l’OWASP Top 10 expliqué aux dirigeants.
Quand faut-il faire un test d’intrusion ?
Le bon moment dépend de l’exposition de l’application et de ce qu’elle contient. Voici les déclencheurs que nous recommandons de prévoir dans la feuille de route.
- Avant la première mise en production d’une application accessible depuis Internet, surtout si elle héberge des données clients, financières ou personnelles. Planifiez le test quelques semaines avant la date cible, pour garder le temps de corriger.
- Après une évolution majeure : ouverture d’un portail client, nouvelle API publique, changement du mode d’authentification, intégration d’un assistant d’IA générative, migration d’hébergement.
- À intervalle régulier, souvent annuel, pour les applications critiques, car les techniques d’attaque et les composants évoluent même quand le code ne change pas.
- À la demande d’un tiers : un donneur d’ordre qui l’exige dans son questionnaire de sécurité, un assureur cyber, une démarche de certification, ou les obligations d’évaluation des mesures de sécurité prévues pour les entités soumises à NIS2.
- Après un incident, pour vérifier que la faille exploitée est corrigée et qu’il n’en existe pas d’autres du même type.
À l’inverse, un pentest sur une application encore instable, dont les écrans changent chaque semaine, a peu de valeur : le rapport sera périmé avant d’être lu.
Boîte noire, grise ou blanche : quel niveau d’information donner ?
Le niveau d’information transmis à l’auditeur change profondément ce que le test peut trouver.
- Boîte noire : l’auditeur part de l’adresse de l’application, sans compte ni documentation, comme un attaquant extérieur. Utile pour mesurer l’exposition publique, mais il passe beaucoup de temps à découvrir ce que vous auriez pu lui dire.
- Boîte grise : il dispose de comptes de test pour chaque rôle (utilisateur, responsable, administrateur client, partenaire) et d’une description des parcours. C’est le format le plus rentable pour une application métier, car il permet de vérifier qu’un utilisateur d’une entreprise ne peut pas lire les données d’une autre.
- Boîte blanche : il a accès au code source, à l’architecture et à la configuration. Le test est plus exhaustif et se rapproche d’un audit de code.
Le guide de l’OWASP souligne que beaucoup de problèmes importants sont difficiles à trouver en boîte noire. Or la première catégorie de risques de l’OWASP Top 10 2025, le contrôle d’accès défaillant, se teste précisément en comparant ce que voient des comptes de rôles différents. Une bonne matrice des droits devient alors le meilleur support de l’auditeur.
Comment choisir un prestataire ?
Un test d’intrusion donne à un tiers un accès privilégié à votre système et à vos failles. La confiance dans le prestataire est donc essentielle.
En France, l’ANSSI qualifie des prestataires d’audit de la sécurité des systèmes d’information (PASSI). D’après le catalogue officiel de l’ANSSI, mis à jour au moins une fois par mois, ces prestataires peuvent être qualifiés pour une ou plusieurs de cinq activités : audit organisationnel et physique, audit d’architecture, audit de configuration, audit de code source et tests d’intrusion. La qualification n’est pas obligatoire pour toutes les entreprises, mais elle constitue un repère solide, et elle est exigée dans certains contextes réglementaires.
Au-delà du label, posez ces questions :
- Qui réalisera concrètement les tests, et quelle est leur expérience sur des applications web comparables ?
- Quelle méthodologie suivez-vous ? Les références habituelles sont le guide de test de l’OWASP et son standard de vérification ASVS.
- Pouvez-vous montrer un exemple de rapport anonymisé ?
- Le contre-test après correction est-il inclus ?
- Comment sont protégées les informations que vous collectez sur nos failles ?
Préparer le test : la liste de contrôle
Une bonne préparation fait gagner des jours d’audit et évite les mauvaises surprises.
- Délimiter le périmètre : adresses, API, application mobile, espaces exclus, et ce qui est interdit (déni de service, ingénierie sociale, tests sur la production).
- Signer une autorisation écrite : l’accès frauduleux à un système d’information est un délit au sens de l’article 323-1 du Code pénal. La convention d’audit protège l’auditeur et vous. Si l’application est hébergée chez un tiers, prévenez-le et vérifiez ses conditions.
- Préparer un environnement identique à la production, alimenté avec des données fictives réalistes.
- Créer des comptes de test pour chaque rôle et pour au moins deux entreprises clientes différentes, afin de tester l’étanchéité entre elles.
- Faire une sauvegarde de l’environnement de test et prévenir l’équipe d’exploitation des dates, pour qu’une alerte de sécurité ne déclenche pas une fausse crise.
- Désigner un interlocuteur joignable pendant le test, capable de débloquer un accès ou d’arrêter l’exercice si nécessaire.
Lire le rapport et corriger
Un rapport de test d’intrusion contient en général une synthèse pour la direction, puis une fiche par vulnérabilité : description, preuve d’exploitation, niveau de criticité, recommandation de correction. Trois réflexes aident à en tirer parti.
Prioriser selon le risque métier, pas seulement selon la note. Une faille « moyenne » qui permet de télécharger les factures de tous les clients peut mériter plus d’urgence qu’une faille « haute » sur une page d’administration interne déjà protégée par un VPN.
Corriger la cause, pas le symptôme. Si l’auditeur trouve qu’un écran ne vérifie pas la propriété d’un dossier, la vraie correction est de centraliser ce contrôle pour tous les écrans, puis d’ajouter des tests automatisés qui empêcheront la régression.
Programmer le contre-test. Une fois les corrections déployées, l’auditeur vérifie qu’elles sont efficaces. C’est la seule preuve à présenter à un client ou un assureur.
Le pentest ne suffit pas : intégrer la sécurité au développement
Le guide de l’OWASP est sans ambiguïté : utilisé seul, le test d’intrusion arrive « too little too late », trop peu et trop tard dans le cycle de développement. Il rappelle qu’un défaut détecté tôt se corrige plus vite et à moindre coût. La CNIL recommande de son côté des tests complets, y compris de sécurité, et une revue de code avant toute mise en production d’une mise à jour.
Concrètement, une application bien construite combine :
- des exigences de sécurité écrites dès le cadrage, en s’appuyant sur l’ASVS ;
- des revues de code systématiques et des analyses automatiques à chaque livraison ;
- des tests automatisés des droits d’accès ;
- une mise à jour régulière des composants, prévue dans le contrat de maintenance ;
- un test d’intrusion aux moments clés, pour valider l’ensemble avec un regard extérieur.
Le pentest devient alors une vérification, pas une découverte. Vous préparez la mise en production d’une application exposée, ou vous devez répondre à l’exigence de sécurité d’un client ? Décrivez votre projet dans notre diagnostic en ligne : nous vous aiderons à définir le bon périmètre et le bon calendrier.
