Test d'intrusion d'application web

Vous avez une application en production. Elle gère des comptes clients, des données personnelles, peut-être des paiements. Personne n’a jamais sérieusement essayé de la casser, et la question commence à remonter. Un client vous envoie un questionnaire sécurité, un auditeur demande des preuves, ou vous avez simplement lu l’actualité ce matin.

Un test d’intrusion répond à une question précise : qu’est-ce qu’un attaquant peut réellement obtenir, et par où ?

Pas « avez-vous des vulnérabilités », la réponse est toujours oui, mais lesquelles sont exploitables, dans quel ordre, et avec quel impact concret sur votre métier.

Pourquoi maintenant

L’exploitation de vulnérabilités est devenue le premier vecteur d’entrée des compromissions : 31 %, devant le phishing (16 %) et l’abus d’identifiants (13 %). C’est le constat du Verizon DBIR 2026, établi sur plus de 22 000 compromissions confirmées dans 145 pays entre octobre 2024 et novembre 2025. L’ordre s’est inversé : pendant des années, le vol d’identifiants dominait.

Le même rapport donne le revers de la médaille. En 2025, seules 26 % des vulnérabilités critiques ont été entièrement corrigées, contre 38 % l’année précédente. Le délai médian de résolution complète est passé de 32 à 43 jours. L’exploitation accélère pendant que la correction ralentit.

Pour les PME, le rapport est encore plus dur : trois schémas d’attaque pour 100 % des compromissions observées :

• l’intrusion système
• les attaques web basiques
• l’ingénierie sociale

En France, le Panorama de la cybermenace 2025 de l’ANSSI recense 1 366 incidents confirmés, un niveau stable par rapport à 2024 (1 361). Les signalements, eux, baissent de 18 %, mais l’ANSSI attribue en partie cette baisse au pic lié aux Jeux de Paris 2024, pas à une détente. En revanche, les incidents d’exfiltration de données passent de 130 à 196 en un an.

La conclusion utile : votre surface web exposée est la porte d’entrée la plus empruntée, et savoir ce qu’elle laisse passer coûte beaucoup moins cher que de l’apprendre autrement.

Quand lancer un test

Les déclencheurs les plus fréquents :

• Avant une mise en production majeure : nouvelle application, refonte, ouverture d’une API à des partenaires.
• Après un changement d’architecture : migration cloud, découpage en microservices, changement de fournisseur d’authentification.
• Parce qu’un tiers le demande : appel d’offres, due diligence, questionnaire sécurité d’un grand compte, exigence d’un assureur.
• Pour une obligation réglementaire : l’article 32 du RGPD impose des mesures techniques appropriées, incluant explicitement « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité » de ces mesures. Les cadres NIS2 et DORA renforcent cette exigence de tests réguliers pour les entités concernées.
• Après un incident : pour mesurer l’étendue réelle et confirmer que la porte est bien refermée.
• En cycle : une fois par an, ou à chaque version majeure, selon le rythme de vos déploiements.

Si aucun de ces cas ne s’applique et que personne ne vous le demande, un test d’intrusion n’est peut-être pas votre priorité. Commencer par une formation des développeurs coûte moins cher et évite de payer pour faire constater les mêmes classes de failles à chaque audit.

Ce que je teste

Le périmètre est défini avec vous au cadrage. Les tests suivants sont mon terrain de chasse depuis 10 ans sur une application web type, voir mes CVEs et mes articles techniques :

• Authentification et gestion de session : énumération de comptes, réinitialisation de mot de passe, limitation de débit, attributs de cookies, fixation et détournement de session, multi-facteur…
• Contrôle d’accès : élévation horizontale et verticale, références directes d’objets, cloisonnement entre comptes. C’est la catégorie A01 de l’OWASP Top 10:2025, et toujours la première source de trouvailles sérieuses en pratique.
• Injections : SQL et NoSQL, commandes système, code, templates, injection côté client…
• Traitement des fichiers : upload arbitraire, traversée de chemin, inclusion locale et distante, stockage et servitude des fichiers déposés.
• Logique métier : enchaînements d’étapes contournables, manipulation de montants ou de quantités, conditions de course. C’est ce qu’aucun scanner ne trouve.
• Configuration et exposition : en-têtes, Content Security Policy, CORS, messages d’erreur verbeux, secrets côté client, dépôts Git et sauvegardes accessibles, fuites d’API…
• Surface d’attaque périphérique : sous-domaines oubliés, services annexes, secrets publiés par inadvertance.

Non, ça ne ressemble pas à ça. En vrai : beaucoup de lecture de code, un tableur de suivi, et trois cafés avant d’expliquer pourquoi un identifiant de commande incrémental est un problème.

Comment ça se déroule

1. Cadrage : périmètre technique, comptes de test, environnement (recette ou production), fenêtre d’intervention, contacts d’urgence, convention d’audit signée. Rien ne commence avant cette signature.

2. Reconnaissance : cartographie de la surface réellement exposée. C’est souvent la première surprise : l’inventaire que vous avez en tête et ce qui est joignable depuis Internet ne coïncident que rarement.

3. Cartographie fonctionnelle : parcours utilisateurs, rôles, points d’entrée, endpoints d’API. L’objectif est de comprendre l’application avant de l’attaquer, sinon on teste au hasard.

4. Tests manuels : le cœur du travail. L’outillage sert à paralléliser (Burp Suite Pro, SQLmap, scripts dédiés), pas à décider. Référentiels utilisés : l’OWASP Web Security Testing Guide pour la couverture, l’OWASP ASVS pour le niveau d’exigence, PTES pour la structure globale.

5. Exploitation mesurée : démontrer l’impact sans dégrader le service. Une preuve d’exploitation, pas une démonstration de force. Les actions destructives sont exclues par défaut et ne sont jamais tentées sans accord écrit explicite.

6. Rapport et restitution : livrable écrit, puis un échange avec vos développeurs.

Le rapport

C’est le livrable, et c’est la partie que la plupart des prestataires bâclent.

• Une synthèse d’une page, sans jargon, lisible par une direction : ce qui a été testé, ce qui a été trouvé, ce qu’il faut corriger en premier.
• L’inventaire des vulnérabilités, chacune avec son score CVSS, une criticité contextualisée à votre environnement, le scénario d’attaque complet et les étapes reproductibles.
• Des preuves exploitables : requêtes brutes, captures, conditions de reproduction. Votre développeur doit pouvoir rejouer la faille sans me rappeler.
• Des recommandations priorisées, classées par impact rapporté à l’effort de correction, et pas une liste alphabétique de bonnes pratiques génériques.
• Une restitution orale avec l’équipe technique, pour les questions qui ne tiennent pas dans un document.

Une page d’administration accessible publiquement est une information, pas une vulnérabilité critique. Gonfler les scores remplit le rapport et vide sa valeur : au troisième audit où tout est « élevé », plus personne ne le lit, et la seule trouvaille réellement critique se noie dans le bruit. Acceptez les rapports courts quand l’application est saine !

Ce qu’un test d’intrusion n’est pas

Autant le dire avant de signer :

• Ce n’est pas un scan automatisé rebadgé. Si le rapport ressemble à un export d’outil, vous avez payé une licence, pas une expertise.
• Ce n’est pas exhaustif. Le temps est borné, donc la couverture l’est aussi. Un test d’intrusion donne une photographie, à une date, sur un périmètre, avec un budget. Il ne prouve pas l’absence de failles, rien ne le prouve.
• Ce n’est pas un audit de code. Les deux sont complémentaires : le pentest voit ce qui est exploitable de l’extérieur, l’audit de code voit ce qui est fragile de l’intérieur.
• Ce n’est pas un bug bounty. Un programme de bug bounty vous achète de la durée et de la diversité d’approches ; un test d’intrusion vous achète de la profondeur et de la traçabilité sur un périmètre défini. J’ai pratiqué les deux côtés et je peux vous dire lequel correspond à votre situation, y compris quand la réponse est « aucun des deux, pour l’instant ».
• Ça ne corrige rien tout seul. Rappel du chiffre plus haut : 74 % des vulnérabilités critiques ne sont pas corrigées. Un rapport qui finit dans un dossier partagé n’a amélioré la sécurité de personne.

Pourquoi moi

Environ 25 ans de développement web, puis la sécurité à plein temps.

• Auditeur pour le ministère des Armées, de 2020 à 2024 : tests d’intrusion, audits de configuration selon les recommandations de l’ANSSI, et audits de code sur des systèmes Linux et des applications web.
• Chasseur de vulnérabilités depuis 2016 : plusieurs centaines de rapports soumis à des startups, grands comptes et institutions publiques. Dont des prises de contrôle de sous-domaines, injections SQL, SSRF, exécution de commandes à distance, prise de contrôle complète d’un compte AWS et bien d’autres…
• Des CVEs publiées sous mon nom : voir la liste.
• Formateur depuis 2022 : une dizaine de formations dispensées, ce qui veut dire que je sais expliquer une faille à l’équipe qui devra la corriger.
• Développeur avant tout le reste : je lis votre code sans traducteur, et mes recommandations tiennent compte de ce qu’elles coûtent à implémenter.

Un exemple public de ce que ça donne : mon analyse d’une application médicale française critique.

Questions fréquentes

Combien de temps ? Trois à dix jours d’intervention selon le périmètre, plus la rédaction. Une application métier de taille moyenne tourne autour de cinq jours.

Combien ça coûte ? Devis sur demande, au forfait. Les facteurs : nombre de fonctionnalités et de rôles, présence d’une API, disponibilité d’un environnement de test, et nécessité d’une contre-vérification. Je donne une fourchette dès le premier échange, avant tout engagement.

Boîte noire ou boîte grise ? Boîte grise dans la grande majorité des cas, avec des comptes de test pour chaque rôle. Un attaquant réel finit par obtenir un compte ; me les refuser fait dépenser votre budget à franchir une porte au lieu d’explorer ce qu’il y a derrière.

Est-ce que ça peut casser la production ? Le risque n’est jamais nul, c’est pourquoi un environnement de recette iso-production est préférable. Sur production, les tests intrusifs sont écartés, la fenêtre est convenue à l’avance, et vous avez mon numéro pendant toute la durée.

Et si vous ne trouvez rien de grave ? Vous obtenez un rapport qui le dit, avec le détail de ce qui a été testé et comment. C’est un document utile à présenter à un client ou à un auditeur, et c’est le résultat que je préfère.

Enfin, si vos équipes veulent monter en compétence pour ne plus retrouver les mêmes catégories de failles l’année prochaine, c’est exactement l’objet de mes formations.

Parlons-en

Décrivez-moi votre application en quelques lignes : ce qu’elle fait, qui l’utilise, ce qui vous inquiète. Je vous réponds avec un périmètre proposé et une fourchette de prix.

Gwendal Le Coguic - contact@glc.st - devis sur demande - SIRET 79778302400038