Test d'intrusion web, mené comme une vraie attaque.
Un test d'intrusion web consiste à attaquer votre application dans les mêmes conditions qu'un adversaire réel, avec votre autorisation écrite et un périmètre défini, pour identifier les failles exploitables avant qu'elles ne le soient contre vous. Je le fais manuellement, parce que les vulnérabilités qui coûtent cher ne sont pas celles qu'un outil ou une IA sait reconnaître.
Le scanner a dit « RAS ». Ça ne veut rien dire.
Un scanner de vulnérabilités compare votre application à un catalogue de signatures connues. Il détecte une version d'un composant qui traîne, un en-tête absent, parfois une injection évidente. C'est utile, et ça devrait tourner en continu chez vous : scan et test d'intrusion ne répondent pas à la même question.
Mais un scanner ne sait pas ce qu'est une commande, un dossier médical ou un contrat. Il ne se demande jamais si l'identifiant 4172 dans une URL peut être remplacé par 4173 pour lire le document du client d'à côté. Il ne remarque pas qu'un utilisateur au rôle « lecture seule » peut appeler directement l'action de suppression parce que le bouton a été masqué côté interface, mais pas côté serveur. Ces failles n'ont pas de signature : elles sont propres à votre métier.
C'est exactement là que je cherche. Les rapports que je remets sont majoritairement constitués de ce type de failles, et ce sont celles qui déclenchent des incidents réels.
Ce que je teste.
Sur une application web classique, l'essentiel du risque se concentre sur quelques familles de vulnérabilités. Voici celles que je couvre systématiquement.
- Contrôles d'accès horizontaux et verticaux : IDOR, accès aux données d'un autre utilisateur, élévation de privilèges.
- Authentification et sessions : réinitialisation de mot de passe, contournement de second facteur, jetons prévisibles, déconnexion incomplète.
- Injections : SQL, NoSQL, commandes système, templates côté serveur, XSS stockées et reflétées.
- Logique métier : prix négatifs, remises cumulables, étapes de tunnel sautées, quotas contournés, workflows rejouables.
- Upload et traitement de fichiers : exécution, traversée de chemin, écrasement de fichiers existants.
- Configuration et exposition : SSRF, CORS trop permissif, sauvegardes accessibles, messages d'erreur bavards, secrets dans le code livré au navigateur.
Comment se passe une mission.
Cadrage
Un échange pour comprendre ce que fait votre application, ce qui vous inquiète, et ce qui serait grave si ça arrivait. On fixe le périmètre exact, les domaines concernés, ce qui est exclu, et la fenêtre de test. Contrat de test et NDA signés avant tout accès.
Reconnaissance
Cartographie complète : sous-domaines, points d'entrée, technologies, rôles, flux de données. L'objectif est d'avoir une carte plus complète que celle de vos propres équipes, parce qu'un attaquant ne se limite pas aux pages du menu.
Exploitation manuelle
La partie longue. Je manipule les requêtes, je change les identifiants, je rejoue les workflows dans le désordre, je m'authentifie avec un rôle et j'agis avec les droits d'un autre. Chaque hypothèse est testée jusqu'à obtenir une preuve ou une certitude que ça ne passe pas.
Qualification de l'impact
Une faille n'a d'intérêt que par ce qu'elle permet. Pour chaque trouvaille, j'établis ce qu'un attaquant obtiendrait réellement, avec une preuve de concept reproductible pas à pas.
Rapport et débrief
Un rapport priorisé par criticité réelle, avec l'impact métier en langage clair pour vos décideurs et la remédiation concrète pour vos développeurs. Puis un débrief en direct avec l'équipe pour répondre aux questions.
Retest
Une fois vos correctifs déployés, je revérifie chaque faille. Un correctif qui ne corrige qu'un cas sur deux est un correctif qui n'existe pas, et ça arrive plus souvent qu'on ne le croit. Le retest est inclus.
Ce que ça donne en pratique.
Failles réelles, trouvées, signalées et corrigées. Les clients et les périmètres ne sont jamais divulgués.
Combien ça coûte.
Sur devis, et voici pourquoi : un tarif au forfait affiché sans connaître le périmètre serait faux dans les deux sens. Ce qui fait varier le prix :
Le nombre de rôles à tester, d'abord. Chaque rôle supplémentaire multiplie les combinaisons de contrôle d'accès à vérifier, et c'est là que se cachent les failles les plus graves. Ensuite la taille fonctionnelle : un site vitrine avec un formulaire de contact n'a rien à voir avec une plateforme métier à quarante écrans. Puis la présence d'une API, d'un tunnel de paiement, d'un SSO ou d'intégrations tierces, qui ajoutent chacun une surface propre. Enfin la profondeur attendue : une passe de qualification rapide ou une recherche approfondie.
Le premier échange est sans engagement et sert précisément à cadrer tout ça. Si votre besoin est plus léger que ce que vous imaginiez, je vous le dirai.
Questions fréquentes.
Un test d'intrusion peut-il casser mon site en production ?
Non. Je travaille en lecture et en preuve de concept minimale : je démontre qu'un accès est possible, je ne l'exploite pas au-delà. Les tests susceptibles de dégrader le service, comme le déni de service ou l'envoi massif, sont exclus par défaut et ne sont menés que sur demande écrite, dans une fenêtre convenue.
Combien de temps dure un test d'intrusion web ?
Entre quelques jours et plusieurs semaines selon le périmètre. Une application vitrine avec un formulaire se traite vite. Un back-office avec dix rôles, un tunnel de paiement et une API demande nettement plus. La durée est fixée au cadrage, avant signature.
Faut-il me donner des comptes de test ?
C'est fortement recommandé. Un test en boîte grise, avec un compte par rôle, trouve beaucoup plus de failles de contrôle d'accès qu'un test purement externe, parce que les failles les plus graves se cachent derrière l'authentification. Sans compte, tout ce qui est réservé aux utilisateurs connectés reste hors de portée.
Quelle différence avec un scanner de vulnérabilités ?
Un scanner compare votre application à une base de signatures connues. Il ne comprend pas votre logique métier, donc il ne verra jamais qu'un identifiant de commande dans une URL permet de lire la commande d'un autre client. La recherche manuelle existe pour ça.
Le retest est-il facturé en plus ?
Non. Vérifier que vos correctifs tiennent fait partie de la mission. Un rapport dont personne ne vérifie les corrections n'a pas rempli son objectif.
Les autres prestations.
Audit de sécurité d'API
Si votre logique métier vit derrière des endpoints REST, JSON ou GraphQL consommés par un front ou une application mobile, c'est là qu'il faut chercher.
DécouvrirAudit de sécurité de site web
Si votre périmètre est un site vitrine, une boutique en ligne ou un site sous CMS plutôt qu'une application à plusieurs rôles, c'est l'autre mission qu'il vous faut.
DécouvrirFaites tester votre application.
Décrivez-moi le périmètre : ce que fait l'application, combien elle a de rôles, et ce qui vous inquiète. Je vous réponds avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.