Test de pénétration d'applications web : Guide 2026

Qu'est-ce que le test d'intrusion d'applications web ?

Le test d'intrusion d'applications web est une évaluation de sécurité structurée dans laquelle un testeur sonde manuellement une application web à la recherche de vulnérabilités, en simulant les techniques qu'un vrai attaquant utiliserait. Il va au-delà du scan automatisé en testant la logique métier, les flux d'authentification et les mécanismes de contrôle d'accès que les outils ne peuvent pas évaluer seuls.

La distinction entre un audit de vulnérabilités et un test d'intrusion est importante. Un audit de vulnérabilités exécute des outils automatisés et rapporte ce qu'ils trouvent. Un test d'intrusion d'application web va plus loin : le testeur vérifie manuellement chaque problème, tente l'exploitation, chaîne les vulnérabilités entre elles et démontre l'impact réel. Un scanner peut signaler un XSS réfléchi. Un pentester chaîne ce XSS en vol de session et prouve qu'il peut prendre le contrôle d'un compte administrateur.

Selon l'OWASP Web Security Testing Guide v4.2, le test d'applications web couvre 12 catégories majeures, de la collecte d'informations au test d'API. En pratique, la plupart des constats critiques se concentrent autour de trois domaines : les failles d'injection, le contrôle d'accès défaillant et les faiblesses d'authentification. Le DBIR 2024 de Verizon a constaté que les applications web étaient le vecteur initial dans 26 % des brèches confirmées, ce qui en fait la surface d'attaque la plus importante pour la majorité des organisations.

La durée standard d'une mission de pentest web va de 5 à 15 jours ouvrables, selon la complexité de l'application. Un simple site vitrine avec un formulaire de connexion prend une semaine. Une plateforme SaaS d'entreprise avec isolation multi-tenant, intégrations API et contrôle d'accès basé sur les rôles nécessite deux à trois semaines pour être testée correctement.

Méthodologie de test d'intrusion d'applications web

Tout testeur expérimenté suit une méthodologie, pas une checklist. Les checklists donnent une fausse assurance d'avoir tout couvert. Une méthodologie offre un processus reproductible qui s'adapte à l'architecture de chaque application. La méthodologie de test d'intrusion web ci-dessous s'appuie sur l'OWASP Testing Guide et le PTES, affinée par l'expérience de missions réelles.

Reconnaissance et validation du périmètre

Avant de toucher à l'application, validez votre périmètre. Cela semble évident, mais les dépassements de périmètre mettent fin à des missions et à des carrières. Relisez le document de règles d'engagement deux fois. Confirmez quels domaines, sous-domaines et plages IP sont dans le périmètre. Si le périmètre indique app.example.com, ne sondez pas api.example.com sauf si c'est explicitement listé.

Commencez par la reconnaissance passive. Les enregistrements WHOIS révèlent les hébergeurs et les détails du titulaire. L'énumération DNS avec des outils comme dig et amass découvre des sous-domaines que le client a peut-être oubliés. Vérifiez les logs de transparence des certificats via crt.sh pour les sous-domaines ayant reçu des certificats SSL. Le Google dorking avec site:target.com filetype:pdf fait remonter des documents exposés.

La reconnaissance active vient ensuite. Le scan de ports avec Nmap identifie les services ouverts. Pour les applications web spécifiquement, les ports qui vous intéressent sont 80, 443, 8080, 8443 et tout port non standard exécutant HTTP. Un rapide nmap -sV -p 80,443,8080,8443 target.com confirme ce avec quoi vous travaillez.

Cartographie de l'application

La cartographie applicative construit votre modèle mental du fonctionnement de la cible. Vous devez comprendre chaque endpoint, paramètre, mécanisme d'authentification et rôle utilisateur avant de commencer les tests.

Configurez Burp Suite comme proxy de votre navigateur et parcourez l'intégralité de l'application. Créez un compte à chaque niveau de permission fourni par le client (utilisateur, modérateur, administrateur). Naviguez sur chaque page, soumettez chaque formulaire, déclenchez chaque appel AJAX. La site map de Burp se remplit au fur et à mesure de votre navigation, vous donnant une représentation visuelle de la surface d'attaque de l'application.

Portez attention à :

• Les mécanismes d'authentification (cookies de session, JWTs, clés API, flux OAuth)
• Les champs de saisie et paramètres d'URL acceptant des données contrôlées par l'utilisateur
• Les endpoints API visibles dans les fichiers JavaScript ou le trafic réseau
• Les fonctionnalités d'upload de fichiers et la gestion des types de contenu
• Les différences de contrôle d'accès basé sur les rôles entre niveaux d'utilisateurs

Lancez la découverte de contenu en parallèle. Gobuster avec une wordlist comme raft-medium-directories.txt trouve des endpoints cachés, des panneaux d'administration et des fichiers de sauvegarde qui ne sont pas liés dans l'interface. Un simple gobuster dir -u https://target.com -w raft-medium-directories.txt -t 50 révèle souvent plus de surface d'attaque qu'une heure de navigation manuelle.

Découverte de vulnérabilités

C'est le cœur de l'audit. Vous testez systématiquement chaque point d'entrée et chaque fonctionnalité à la recherche de faiblesses. Les trois classes de vulnérabilités qui dominent les constats réels des audits web sont les failles d'injection, le contrôle d'accès défaillant et les problèmes d'authentification.

Pour les tests d'injection, commencez avec des payloads manuels avant de sortir les outils automatisés. Injectez une apostrophe dans chaque paramètre et observez la réponse. Une erreur 500 ou un message d'erreur de base de données confirme un potentiel d'injection SQL. Testez avec 1' OR '1'='1 dans les formulaires de connexion. Essayez <script>alert(1)</script> dans les champs de recherche et les sorties contrôlées par l'utilisateur pour le XSS. Testez l'injection de commandes avec ; id ou | whoami dans les paramètres susceptibles d'interagir avec le système d'exploitation.

Pour les tests de contrôle d'accès, connectez-vous en tant qu'utilisateur à faibles privilèges et tentez d'accéder aux ressources d'autres utilisateurs. Changez un paramètre id=123 en id=124 et vérifiez si vous obtenez les données d'un autre utilisateur. Accédez directement aux endpoints administrateur sans identifiants admin. En pratique, le contrôle d'accès défaillant apparaît dans environ 80 % des audits d'applications web. C'est le constat le plus fréquent parce que les développeurs se concentrent sur la création de fonctionnalités, pas sur la restriction de leur accès.

Les tests d'authentification couvrent les politiques de mot de passe, les mécanismes de verrouillage de compte, la gestion des sessions et les contournements d'authentification multi-facteurs. Vérifiez si les sessions expirent après déconnexion. Confirmez que les jetons de réinitialisation de mot de passe sont à usage unique et limités dans le temps. Testez si l'application accepte les identifiants en HTTP non chiffré.

Exploitation et preuve de concept

Trouver une vulnérabilité ne suffit pas. Vous avez besoin d'une preuve de concept fonctionnelle qui démontre un impact réel. Un client ne priorisera pas la correction d'un XSS si vous dites simplement "ce paramètre est réfléchi". Montrez-lui un payload qui vole son cookie de session administrateur et redirige vers un serveur contrôlé par l'attaquant.

Le chaînage de vulnérabilités sépare les bons pentesters des excellents. Un IDOR qui divulgue des adresses email a une sévérité moyenne seul. Chaînez-le avec un flux de réinitialisation de mot de passe qui envoie des jetons à ces adresses, et vous obtenez une prise de contrôle de compte. Un SSRF qui lit des métadonnées internes peut sembler limité jusqu'à ce que vous extrayiez des identifiants AWS depuis http://169.254.169.254 et pivotiez vers l'infrastructure cloud.

Documentez tout au fur et à mesure. Capturez chaque étape, sauvegardez les requêtes et réponses HTTP depuis Burp, et notez les étapes exactes de reproduction. Le rapport est là où vous apportez de la valeur, et une documentation bâclée pendant les tests signifie des heures de reconstitution pénible par la suite.

Rapport et recommandations de remédiation

Un rapport de pentest est le seul livrable que votre client conserve. Les tests eux-mêmes sont éphémères, le rapport est permanent. Rédigez-le pour deux audiences : les dirigeants qui doivent comprendre le risque, et les développeurs qui doivent corriger les problèmes.

Chaque constat devrait inclure :

• Un titre clair et un score CVSS 3.1
• L'URL affectée, le paramètre et la méthode HTTP
• Des instructions de reproduction étape par étape
• Des captures d'écran ou des paires requête/réponse HTTP comme preuves
• Une explication de l'impact métier (pas seulement l'impact technique)
• Des recommandations de remédiation spécifiques avec des exemples de code quand c'est possible

Oubliez les conseils génériques du type "assainissez toutes les entrées". Dites au développeur exactement quelle fonction utiliser : "Utilisez des requêtes paramétrées avec PreparedStatement en Java" ou "Appliquez DOMPurify.sanitize() avant de rendre du contenu utilisateur." Les remédiations concrètes sont corrigées. Les conseils vagues sont ignorés.

Outils essentiels pour le test d'intrusion d'applications web

Vous n'avez pas besoin de 15 outils pour tester une application web. Vous en avez besoin de trois, bons, et d'une connaissance approfondie de leur utilisation. Voici les outils de test d'intrusion d'applications web sur lesquels les professionnels s'appuient réellement.

Burp Suite

Burp Suite est au centre de chaque mission d'audit web. Il se place entre votre navigateur et la cible en tant que proxy d'interception, vous permettant de visualiser, modifier et rejouer chaque requête HTTP. La Community Edition est gratuite et gère la plupart des tâches. La Pro Edition ajoute un scanner automatisé, la pleine vitesse d'Intruder et Collaborator pour les tests hors bande.

Les fonctionnalités que vous utiliserez au quotidien : Proxy pour intercepter les requêtes, Repeater pour modifier et renvoyer des requêtes individuelles, Intruder pour le fuzzing de paramètres, et la site map pour comprendre la structure de l'application. Si vous débutez avec Burp, suivez notre tutoriel Burp Suite avant votre première mission.

En pratique, je garde Burp ouvert pendant tout l'audit. Chaque requête intéressante est envoyée dans Repeater. Chaque paramètre méritant d'être fuzzé passe par Intruder. L'historique du Proxy devient ma piste d'audit.

SQLMap

Une fois que vous avez confirmé manuellement qu'un paramètre est vulnérable à l'injection SQL, SQLMap automatise l'extraction. Il gère l'injection aveugle, l'injection basée sur le temps, les requêtes UNION et les requêtes empilées sur des dizaines de backends de bases de données.

Le workflow professionnel : trouvez le point d'injection manuellement, sauvegardez la requête depuis Burp en fichier texte, puis pointez SQLMap dessus :

sqlmap -r request.txt --batch --level=3 --risk=2

N'exécutez jamais SQLMap contre une application de production sans autorisation écrite explicite et périmètre confirmé. L'outil génère des centaines de requêtes et peut déclencher des alertes WAF, faire crasher des applications instables ou modifier des données avec des requêtes empilées. Manuel d'abord, automatisé ensuite : c'est l'approche professionnelle.

Pour un guide détaillé des techniques d'injection SQL avant d'automatiser, consultez notre tutoriel d'injection SQL.

Gobuster et ffuf

La découverte de contenu est non négociable. Les répertoires cachés, les fichiers de sauvegarde et les endpoints API non documentés sont souvent le point d'entrée de constats critiques.

Gobuster gère le brute-forcing de répertoires classique avec une configuration minimale. C'est rapide, simple, et ça fait le travail dans 80 % des cas. Consultez notre guide des wordlists Gobuster pour les wordlists recommandées par scénario.

ffuf est plus flexible. Il supporte le filtrage par code de réponse, taille, nombre de mots et nombre de lignes, ce qui compte quand la cible retourne des pages 404 personnalisées. Pour les API, la capacité de ffuf à fuzzer des paramètres JSON et des headers est précieuse.

Oubliez DirBuster. Il fonctionne, mais l'interface Java est douloureusement lente comparée aux alternatives en ligne de commande. Gobuster ou ffuf termineront en une fraction du temps avec une sortie plus propre. Si vous voulez comprendre le concept derrière le brute-forcing de répertoires, notre guide DirBuster couvre les fondamentaux.

Vulnérabilités courantes que vous trouverez

Après des dizaines d'audits d'applications web, des tendances se dessinent. Les mêmes classes de vulnérabilités reviennent encore et encore. Voici les trois qui apparaissent dans quasi tous les rapports.

Injection SQL

L'injection SQL reste l'un des constats les plus impactants en test d'applications web. Bien que documentée depuis la fin des années 1990, elle persiste parce que les développeurs utilisent mal les ORM, écrivent des requêtes brutes pour la "performance", ou héritent de bases de code legacy qui n'ont jamais été corrigées.

Les points d'injection les plus courants : formulaires de connexion, fonctionnalités de recherche, paramètres d'URL utilisés dans les requêtes de base de données et endpoints API acceptant des filtres fournis par l'utilisateur. Un test simple : insérez une apostrophe (') dans un paramètre et observez si la réponse change. Une erreur de base de données, une page différente ou une réponse retardée indiquent toutes une injection potentielle.

L'impact va de l'exfiltration de données (dump de la base entière) à l'exécution de code à distance via xp_cmdshell sur MSSQL ou INTO OUTFILE sur MySQL. Sur une mission, une seule injection SQL aveugle dans un paramètre de recherche a permis d'extraire 2 millions d'enregistrements clients incluant des mots de passe hachés.

XSS et CSRF

Le cross-site scripting et le cross-site request forgery sont des classes d'attaques côté client qui ciblent le navigateur de l'utilisateur plutôt que le serveur. Ce sont des vulnérabilités distinctes avec des mécaniques différentes, mais elles coexistent souvent dans la même application. Pour une analyse détaillée de leurs différences, consultez notre comparaison XSS vs CSRF.

Le XSS réfléchi apparaît quand une entrée utilisateur est incluse dans la réponse HTTP sans encodage. Le XSS stocké est plus dangereux car le payload persiste en base de données et se déclenche pour chaque utilisateur qui consulte la page affectée. Un XSS stocké dans un champ de commentaire, par exemple, peut voler les cookies de session de chaque utilisateur qui lit ce commentaire.

Le CSRF exploite l'inclusion automatique des cookies par le navigateur lors des requêtes same-site. Si une application traite une requête modifiant l'état (changement de mot de passe, mise à jour d'email, transfert de fonds) sans vérifier l'origine de la requête, un attaquant peut créer une page malveillante qui déclenche cette action quand un utilisateur connecté la visite.

Contrôle d'accès défaillant

Le contrôle d'accès défaillant est le constat numéro un du OWASP Top 10 (2021), et pour cause. Il est apparu dans 94 % des applications testées dans le jeu de données OWASP. Cette catégorie couvre tout, de l'IDOR (Insecure Direct Object Reference) au contrôle d'accès manquant au niveau des fonctions.

Le test type : connectez-vous en tant qu'Utilisateur A, trouvez une requête qui accède aux données de l'Utilisateur A (comme GET /api/users/42/profile), changez l'ID pour celui d'un autre utilisateur (43) et vérifiez si vous obtenez ses données. Si oui, c'est un IDOR. Essayez maintenant d'accéder aux endpoints réservés aux administrateurs en tant qu'utilisateur standard. Si /admin/users retourne des données pour une session non-admin, c'est un contrôle d'accès manquant au niveau des fonctions.

Ces vulnérabilités sont partout parce que la plupart des frameworks web n'appliquent pas l'autorisation par défaut. Le framework gère l'authentification (qui êtes-vous ?), mais l'autorisation (qu'avez-vous le droit de faire ?) est laissée au développeur. Et les développeurs, sous pression des délais, oublient souvent d'ajouter ces vérifications à chaque endpoint.

Certifications en test d'intrusion d'applications web

Si vous souhaitez vous spécialiser dans le test d'applications web, trois certifications se distinguent. Chacune valide un niveau de profondeur différent.

BSCP (Burp Suite Certified Practitioner) de PortSwigger est l'option la plus centrée sur le web. L'examen est entièrement pratique, réalisé dans Burp Suite contre des applications réelles. Si votre objectif est spécifiquement le test d'applications web, le BSCP prouve des compétences plus pertinentes que les certifications plus généralistes. Il coûte 99 $ et vous pouvez le repasser le jour même en cas d'échec.

OSCP (Offensive Security Certified Professional) est la certification pentest la plus reconnue dans l'industrie. Elle couvre les applications web dans le cadre d'un programme de sécurité offensive plus large incluant les tests d'intrusion réseau, les attaques Active Directory et l'escalade de privilèges. La composante web est significative mais pas l'unique focus.

eWPT (eLearnSecurity Web Application Penetration Tester) d'INE se situe entre les deux. Elle est centrée sur le web avec un examen pratique qui vous demande de trouver et d'exploiter des vulnérabilités dans une application cible et de livrer un rapport professionnel. Le matériel de formation est plus structuré que l'approche "apprendre par la pratique" de l'OSCP.

Ma recommandation : commencez par le BSCP pour des compétences web ciblées, puis visez l'OSCP quand vous êtes prêt à élargir vers le réseau et les tests AD. Le eWPT est une alternative solide si le style de formation d'INE vous convient mieux.

Considérations légales et éthiques

Au-delà de la légalité, restez dans le périmètre en permanence. Si vous découvrez une vulnérabilité pouvant affecter des systèmes hors périmètre, documentez-la et notifiez le client. Ne l'exploitez pas. Si vous accédez accidentellement à des données sensibles au-delà de ce qui est nécessaire pour votre preuve de concept, arrêtez, documentez le minimum de preuves nécessaires et signalez-le immédiatement.

La divulgation responsable s'applique quand vous trouvez des vulnérabilités en dehors d'une mission formelle. La plupart des organisations ont une politique de divulgation de vulnérabilités ou un programme de bug bounty. En cas de doute, vérifiez la présence d'un fichier /.well-known/security.txt sur le domaine cible.

Pour une pratique sûre et légale, les labs HackerDNA vous offrent des applications web intentionnellement vulnérables à tester dans un environnement sandboxé. Vous acquérez toute l'expérience d'une mission réelle sans aucun risque juridique.