Test d’intrusion applicatif : le guide pour les entreprises tech

Une entreprise tech fait souvent son premier test d’intrusion, ou pentest, à la demande d’un grand compte qui évalue ses fournisseurs. Le délai est court et le prestataire est choisi dans l’urgence. Vous risquez alors de recevoir un rapport qui satisfait le client, mais que vos développeurs peinent à exploiter.

Un test bien préparé a deux usages. Il montre d’abord, preuves à l’appui, comment une faille peut être exploitée dans votre produit, et donne à vos développeurs de quoi la corriger. Son rapport peut ensuite être transmis à un client, à un investisseur ou à un auditeur.

Voici ce qu’il faut savoir avant de lancer le vôtre.

Un scan de vulnérabilités n’est pas un test d’intrusion

C’est une confusion fréquente, et elle peut coûter cher.

Un scan de vulnérabilités est automatisé. L’outil, qu’il examine votre infrastructure, votre application web ou vos dépendances, compare ce qu’il trouve à une base de failles connues. C’est rapide et peu coûteux : lancez-le à chaque livraison, dans votre intégration continue. Mais l’outil ne comprend pas votre logique métier. Il ne sait pas qu’un utilisateur de l’offre gratuite ne doit jamais accéder à la facturation d’un autre compte, ni qu’un numéro de commande séquentiel permet d’énumérer les commandes des autres clients.

Dans un test d’intrusion, un testeur cherche à exploiter les failles, puis à les enchaîner. Les défauts de contrôle d’accès, les élévations de privilèges et les failles de logique métier sont difficiles à détecter automatiquement, car ils dépendent de ce que l’application est censée autoriser.

Les deux se complètent : le scan couvre la surface en largeur et en continu, le test d’intrusion va en profondeur, ponctuellement. Si un prestataire vous propose un « test d’intrusion » livré en 48 heures sans avoir discuté de votre périmètre, il s’agit sans doute d’un scan déguisé.

Quand faire un test d’intrusion

Voici les situations que nous rencontrons le plus souvent :

• À la demande d’un client. C’est le cas classique : un acheteur conditionne la signature du contrat, ou son renouvellement, à un rapport de test récent. La demande est légitime, puisqu’il évalue le risque que vous représentez pour lui.
• Pour répondre à une exigence de conformité. Selon le référentiel visé ou le règlement européen qui vous concerne, le test d’intrusion est une preuve utile, voire l’un des tests attendus. Nous détaillons ces cas dans la partie consacrée à la conformité.
• Avant une mise en production majeure. Nouvelle application, refonte de l’authentification, ouverture d’une API publique : quand la surface d’attaque change en profondeur, c’est le moment de tester.
• Avant une levée de fonds ou un rachat. Lors des vérifications préalables, un investisseur ou un acquéreur veut savoir dans quoi il met son argent. Un rapport de test et un plan de correction répondent d’avance à une partie de ses questions.
• Après un incident. Pour mesurer l’étendue réelle du problème et vérifier qu’il n’est pas la partie émergée d’un défaut plus large.

Si aucun de ces cas ne vous concerne encore mais que vous traitez des données sensibles, un test par an reste une bonne habitude.

Comment se déroule un test d’intrusion applicatif

Nous réalisons nos tests d’intrusion nous-mêmes, sans les sous-traiter. Ils se déroulent en quatre temps. Inutile d’en maîtriser chaque détail technique : en connaître les grandes lignes suffit pour juger un prestataire et savoir ce que vous payez.

011. Le cadrage

Tout commence par la définition du périmètre, l’étape qui détermine la valeur du test. Une cible est un périmètre cohérent : une application web, une API ou une application mobile. Une application web et son API forment une ou deux cibles, selon leur taille et les parcours à tester.

Le cadrage fixe aussi les comptes de test, l’environnement, les exclusions et les dates. De votre côté, vous transmettez les accès, la documentation utile et le nom d’un contact joignable pendant les tests. Un environnement de préproduction convient s’il reproduit fidèlement la configuration, les droits et les fonctionnalités de la production.

Reste à choisir le niveau d’information donné au testeur :

• Boîte noire : le testeur part de zéro, comme un attaquant externe. C’est réaliste, mais une partie du temps sert à cartographier ce que vous connaissez déjà.
• Boîte grise : le testeur dispose de comptes applicatifs et connaît les rôles. L’effort porte sur l’exploitation plutôt que sur la reconnaissance.
• Boîte blanche : le testeur accède en plus au code source. Cela se justifie pour les composants les plus sensibles.

Pour un premier test sur une application métier, la boîte grise est presque toujours le bon choix : c’est le meilleur usage du temps de test.

022. Les tests

Le testeur examine votre application méthodiquement, en s’appuyant sur les guides de l’OWASP (Open Worldwide Application Security Project), une fondation dédiée à la sécurité des applications. Parmi eux figurent le Top 10, qui recense les risques les plus critiques pour les applications web, et le Testing Guide, plus complet. Il passe en revue l’authentification et les sessions, les contrôles d’accès entre comptes et entre rôles, les injections, l’exposition des données, la configuration et la logique métier propre à votre produit. Pour une application mobile, s’y ajoutent le stockage local, la gestion des secrets et les échanges avec l’API.

Pour chaque vulnérabilité, il vérifie qu’elle est réellement exploitable et conserve de quoi la reproduire. Le test doit montrer ce qu’un attaquant peut obtenir, et par quel chemin.

Si votre produit intègre des fonctionnalités d’intelligence artificielle, comme un assistant conversationnel, une recherche augmentée ou un agent, elles font partie de la surface à tester : un modèle mal cadré peut divulguer des données ou déclencher des actions non prévues. Nous les intégrons au cadrage comme toute autre fonctionnalité.

033. Le rapport et la restitution

Le rapport est le livrable central : c’est lui qui distingue un bon test d’un mauvais. Un rapport exploitable s’adresse à deux publics :

• la direction, avec une synthèse lisible sans bagage technique : le niveau de risque global, les constats majeurs, les décisions à prendre ;
• l’équipe technique, avec le détail de chaque vulnérabilité : sa gravité, notée selon le CVSS (Common Vulnerability Scoring System, le barème standard de criticité), son impact métier, les étapes pour la reproduire, les preuves de son exploitation et une correction adaptée à votre environnement technique, pas un simple lien vers une page générique.

Les recommandations sont classées par priorité : vous savez ainsi quoi corriger en premier et à qui confier chaque sujet.

Lors de la restitution, nous présentons le rapport à vos équipes technique et produit, expliquons les scénarios d’attaque, répondons à leurs questions et convenons avec elles de l’ordre des corrections.

044. Le contre-test

Une fois vos corrections en place, un contre-test vérifie que chaque faille est bien fermée et qu’aucune correction n’en a ouvert une nouvelle. Le statut de chaque vulnérabilité est alors mis à jour dans le rapport. Sans contre-test, vous ne savez pas si vos corrections ont fonctionné : vous l’espérez. Chez nous, il est inclus.

Ce que vous devez exiger d’un prestataire

Avant de signer, vérifiez trois points :

1. Un périmètre discuté avec vous, plutôt qu’un forfait fixé sans échange. Le cadrage conditionne tout le reste.
2. Des étapes de reproduction pour chaque vulnérabilité. Une faille que vos développeurs ne peuvent pas reproduire a peu de chances d’être corrigée.
3. Un contre-test inclus, pour vérifier que vos corrections ont bien fermé les failles.

Un rapport qui se contente de reprendre la sortie brute d’un outil de scan, sans reproduction ni priorisation, ne vaut pas son prix, aussi épais soit-il.

Comment le test d’intrusion sert votre conformité

Si vous préparez une certification ou une mise en conformité, le rapport et le suivi des corrections servent aussi de preuves. Ils ne remplacent pas les autres exigences du référentiel ou du règlement.

• ISO 27001, la norme internationale de management de la sécurité de l’information : elle n’impose pas de test d’intrusion. Selon votre analyse de risques, le test peut documenter la gestion des vulnérabilités techniques (mesure 8.8 de l’annexe A) et les tests de sécurité pendant le développement et l’acceptation (mesure 8.29).
• SOC 2, le rapport d’attestation défini par l’AICPA, l’association professionnelle des experts-comptables américains : le test d’intrusion n’y est pas obligatoire, mais ses critères le citent parmi les évaluations qui vérifient que vos contrôles fonctionnent (critère CC4.1).
• DORA, le règlement européen sur la résilience opérationnelle numérique du secteur financier : hors microentreprises, les entités financières doivent tester au moins une fois par an les systèmes et applications informatiques qui soutiennent leurs fonctions critiques ou importantes. Les tests d’intrusion figurent parmi les tests prévus (articles 24 et 25). Seules les entités désignées par leur autorité doivent en plus mener un test d’intrusion fondé sur la menace (TLPT), au moins tous les 3 ans.
• CRA, le règlement européen sur la cyberrésilience (Cyber Resilience Act) : à partir du 11 décembre 2027, les fabricants de logiciels et de produits connectés devront soumettre régulièrement leurs produits à des tests et examens de sécurité efficaces. Le rapport de test pourra rejoindre leur documentation technique. Un service en ligne autonome, sans logiciel installé ni produit connecté qui dépende de lui, n’est pas concerné.

Si vous êtes le prestataire d’une entité financière, les obligations de test de DORA ne vous visent pas directement. Vos clients peuvent en revanche vous demander un rapport de test d’intrusion récent et, si votre service soutient l’une de leurs fonctions critiques ou importantes, votre contrat doit prévoir votre participation à leurs éventuels TLPT.

Lorsque nous vous accompagnons aussi vers la conformité, les constats du test alimentent directement l’analyse de risques et le suivi des corrections.

Délai et budget d’un test d’intrusion

Nous remettons le rapport sous 2 à 4 semaines à partir de la mise à disposition des accès, selon le nombre de cibles à tester. En mission ponctuelle, un test d’intrusion coûte à partir de 6 000 € HT, restitution et contre-test inclus. Le prix dépend du nombre de cibles, de leur taille et des parcours à tester.

Le délai comme le prix dépendent aussi de la préparation : un périmètre restreint et bien documenté se teste plus vite et à moindre coût qu’une application tentaculaire sans documentation.

Le test d’intrusion s’intègre également à nos accompagnements. Il est inclus lorsque nous tenons pour vous le rôle de responsable de la sécurité des systèmes d’information (RSSI), avec l’offre RSSI externalisé, et proposé en option avec l’offre Accompagnement à la conformité. Le périmètre, les livrables et le déroulement sont détaillés sur notre page test d’intrusion applicatif.

Questions fréquentes

N’y a-t-il pas un conflit d’intérêts à vous confier le conseil et le test d’intrusion ?

Un test d’intrusion n’est pas un audit de certification, et nous ne délivrons aucun certificat : c’est le rôle d’un organisme indépendant. Chaque vulnérabilité est documentée avec ses étapes de reproduction, pour que votre équipe ou un tiers puisse la vérifier.

Aidez-vous nos développeurs à corriger les failles ?

Oui. Après la restitution, nous échangeons avec vos développeurs pour expliquer les failles et discuter des corrections possibles dans votre environnement technique. Le contre-test vérifie ensuite que les vulnérabilités sont bien fermées et que les changements n’ont pas créé d’autre problème.

Le test d’intrusion, souvent une première étape

Certains de nos accompagnements commencent par un test d’intrusion demandé par un client, un investisseur ou un partenaire. Le rapport répond au besoin immédiat, puis peut alimenter une analyse de risques ou une démarche de certification.

Mais un test d’intrusion ne vous engage à rien d’autre. Si vous avez seulement besoin de répondre à un client, nous réalisons le test, vous livrons un rapport exploitable, et vous décidez de la suite. Vous envisagez d’aller plus loin ? Parlons de votre projet : si nos offres ne sont pas encore pertinentes pour vous, nous vous le dirons.