Pentest web
Nous testons vos applications web et vos API comme le ferait un attaquant, sur mandat écrit et dans un périmètre défini contractuellement. Ce que nous trouvons, nous l’exploitons : vous savez donc jusqu’où quelqu’un irait réellement, et pas seulement ce qu’un outil a signalé.
Un pentest web — un test d’intrusion applicatif — porte sur l’application telle qu’elle tourne : les écrans, les API REST et GraphQL qui les alimentent, les rôles, les sessions et la logique métier. Nous couvrons aussi les applications mobiles, lourdes et hybrides et, lorsque c’est utile, le code source.
Les cas de test proviennent de l’OWASP Web Security Testing Guide (WSTG) et de l’OWASP ASVS, complétés par des scénarios écrits pour votre métier. L’outillage sert à cartographier et à couvrir le volume ; l’exploitation reste manuelle.
Vous recevez un rapport en français : ce que nous avons trouvé, comment nous l’avons démontré, ce que cela donnerait à un attaquant et la correction à apporter. Le contre-audit est inclus, sans surcoût, dans les 90 jours suivant la remise du rapport.
Ils nous font confiance
Objectifs d’un pentest web
Un pentest web répond à une question que ni un scan de vulnérabilités ni une revue d’architecture ne tranchent : que peut faire aujourd’hui quelqu’un qui s’en prend à votre application, et jusqu’où va-t-il ? Un scanner signale des failles connues ; un test d’intrusion démontre lesquelles sont réellement exploitables chez vous, dans quel ordre les corriger.
Nous cherchons à établir trois choses. D’abord ce qu’un visiteur non authentifié atteint depuis Internet. Ensuite ce qu’un compte légitime — client, partenaire, prestataire, salarié — obtient au-delà de ses droits : les défauts de contrôle d’accès sont la catégorie la plus fréquente de nos rapports, et la moins bien détectée par l’outillage. Enfin la solidité de la logique métier : un panier, un virement, un quota, un circuit de validation se contournent rarement par une injection, mais souvent par une suite d’appels parfaitement légitimes pris un à un.
Un test d’intrusion n’est pas une obligation légale en France. Le RGPD prévoit en revanche, à l’article 32(1)(d), « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». Pour une application qui traite des données personnelles, le pentest est la manière habituelle de documenter cette procédure, et le rapport est la pièce que vous présenterez à un auditeur, à un client grand compte ou à une autorité de contrôle.
Tous nos tests sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal).
Périmètre
Que couvre un pentest applicatif ?
Nous testons l’application telle qu’elle tourne, du navigateur jusqu’aux API qui la servent. Chaque couche a ses faiblesses propres et appelle des cas de test différents. Le périmètre est arrêté avec vous avant le premier paquet envoyé, et ce qui en est exclu est écrit noir sur blanc dans la note de cadrage.
Applications web
Authentification, gestion des sessions, droits par rôle, injections, téléversement de fichiers, en-têtes de sécurité et configuration du serveur. C’est le cœur du pentest web.
API REST et GraphQL
Sur chaque endpoint, nous vérifions l’autorisation, le filtrage des données renvoyées et la logique métier. En GraphQL s’y ajoutent l’introspection, l’imbrication des requêtes et les résolveurs qui contournent les contrôles posés dans l’interface.
Applications mobiles
Ce qui reste sur l’appareil, la façon dont les échanges sont chiffrés et ce que le service dorsal accepte réellement. Le référentiel est l’OWASP MASTG ; le détail figure sur la page pentest mobile.
Applications lourdes et hybrides
Stockage local des données sensibles, privilèges d’exécution, mécanisme de mise à jour et échanges avec le serveur, y compris pour les applications Electron et les clients métier internes.
Audit de code source
L’analyse statique complétée par une relecture manuelle met au jour les validations trop permissives et les défauts de logique qu’on ne voit pas depuis l’extérieur. Nous le combinons volontiers à un test en boîte blanche.
Vulnérabilités
Les vulnérabilités que nous cherchons
La liste ci-dessous n’est pas une grille que nous déroulons mécaniquement : ce sont les familles que nous trouvons le plus souvent, et que nous exploitons pour démontrer l’impact réel. Les cas de test viennent de l’OWASP WSTG et de l’OWASP Top 10, complétés par des scénarios propres à votre application.
Injections
SQL, NoSQL, LDAP, injections de commandes et de gabarits côté serveur. Nous remontons jusqu’à la donnée réellement accessible plutôt que de nous arrêter à la preuve syntaxique.
Authentification et session
Bourrage d’identifiants, réinitialisation de mot de passe, contournement du second facteur, durée de vie et invalidation des jetons, JWT signés avec une clé faible ou acceptés sans vérification de signature.
Contrôle d’accès et IDOR
Accès horizontal aux données d’un autre client, montée en privilèges vers un rôle d’administration, endpoints oubliés qui ne vérifient plus rien. C’est la catégorie la plus fréquente.
Logique métier
Remises cumulées, étapes de validation sautées, quotas contournés, prix rejoués, circuits repris à l’envers. Aucun outil ne détecte cela : il faut d’abord comprendre à quoi sert l’application.
SSRF et services internes
Requêtes forgées depuis votre serveur vers les métadonnées du cloud, vers une console d’administration interne ou vers un stockage non exposé. Dans les environnements AWS, Azure et GCP, une SSRF livre souvent des secrets d’identification.
Désérialisation et exécution de code
Objets sérialisés reçus de l’extérieur, formats binaires propriétaires, désérialisation XML et entités externes (XXE), chaînes de gadgets menant à une exécution de code à distance.
Téléversement et traitement des fichiers
Contrôle du type réel plutôt que de l’extension, stockage hors de la racine web, conversion d’images et génération de PDF, moteurs de rendu qui suivent docilement les liens qu’on leur donne.
Approches : boîte noire, boîte grise, boîte blanche
Le niveau d’information que vous nous transmettez avant la mission détermine ce que nous pouvons couvrir pour un nombre de jours donné. Trois approches coexistent sur le marché français ; nous recommandons la deuxième dans la grande majorité des cas.
Boîte noire (black box)
Nous partons d’une simple URL, sans compte ni documentation, comme un attaquant extérieur. L’approche mesure bien ce qui est visible depuis Internet et la résistance de la surface publique. Sa limite est mécanique : une part importante du budget passe en reconnaissance, et tout ce qui se trouve derrière l’authentification reste hors de portée. Sur une application à comptes clients, un test en boîte noire laisse structurellement de côté la zone où se concentrent les défauts de contrôle d’accès.
Boîte grise (grey box)
Nous disposons d’un jeu de comptes — un par rôle — et d’une description fonctionnelle de l’application. C’est l’approche par défaut d’un pentest web et celle que nous proposons sauf raison contraire : à budget égal, elle couvre davantage de surface, permet de comparer les rôles entre eux et rend le test de la logique métier possible. C’est aussi la seule façon sérieuse de vérifier qu’un client ne voit pas les données d’un autre.
Boîte blanche (white box)
Nous ajoutons le code source, l’architecture et, si nécessaire, un accès aux environnements de recette. L’approche convient aux applications critiques, aux composants de paiement et aux briques maison réutilisées partout. Elle se combine naturellement avec un audit de code source et offre la couverture la plus complète, au prix d’une préparation plus longue de votre côté.
Un test en boîte noire n’est pas « plus réaliste » qu’un test en boîte grise : il est seulement moins informé. Un attaquant réel n’a pas de limite de temps ; une prestation en a toujours une. Le rôle du cadrage est de placer les jours-homme là où ils produisent le plus d’information utile.
Référentiels
Notre méthodologie
Nous travaillons sur des référentiels publics : vous pouvez vérifier ce qui a été testé, comparer deux missions entre elles et redemander la même couverture l’année suivante. L’outillage automatisé sert à cartographier et à couvrir le volume ; l’identification et l’exploitation restent manuelles, et aucune sortie de scanner n’est recopiée telle quelle dans le rapport.
PTES
Le Penetration Testing Execution Standard cadre le déroulement de la mission elle-même : cadrage, collecte de renseignement, modélisation des menaces, exploitation, post-exploitation et restitution.
Déroulement
Déroulement d’un audit d’application web
Une mission type s’étale sur deux à quatre semaines entre le cadrage et la restitution, dont 5 à 15 jours-homme de test effectif. Vous savez à tout moment dans quelle phase nous sommes et ce que nous testons ; les étapes susceptibles de perturber le service sont validées avec vous à l’avance.
Cadrage et note de périmètre
Nous arrêtons ensemble l’application, les rôles, les API et les environnements concernés, ce qui reste hors périmètre, la fenêtre d’intervention et les contacts à joindre en cas d’incident. Tout est écrit avant le premier test.
Reconnaissance et cartographie
Nous recensons les points d’entrée : pages, paramètres, endpoints d’API, dépendances, sous-domaines, en-têtes et technologies. À l’issue de cette phase, la surface d’attaque réelle est connue.
Tests manuels et exploitation
Chaque piste est éprouvée. Une vulnérabilité que nous ne parvenons pas à exploiter ne part pas dans le rapport comme une certitude : vos équipes ne perdent pas de temps sur des alertes sans effet.
Rapport et priorisation
Les constats sont classés par risque, avec le score CVSS, les étapes de reproduction, les preuves et la correction attendue. La synthèse managériale tient en deux pages.
Restitution et contre-audit
Nous présentons les résultats à vos équipes techniques et à votre direction en visioconférence, puis nous revenons vérifier les correctifs. Le contre-audit est inclus, dans les 90 jours suivant la remise du rapport.
Livrables
Livrables : rapport, restitution et contre-audit
L’objectif n’est pas de vous remettre une liste de problèmes, mais un matériau exploitable dès le lendemain par vos développeurs et présentable tel quel à un client ou à un auditeur.
Synthèse managériale
Deux pages sans jargon : ce qui est en jeu, le niveau de risque global et les trois décisions à prendre.
Rapport technique détaillé
Chaque constat avec son score CVSS, les preuves d’exploitation, les étapes de reproduction et la correction recommandée.
Export pour vos équipes
Les constats en CSV ou en JSON, prêts à être importés dans Jira ou Azure DevOps.
Restitution en visioconférence
Une séance avec vos équipes techniques et une lecture destinée à la direction. Les questions se traitent en direct, pas par échange de courriels.
Contre-audit inclus
Après correction, nous revérifions les constats concernés et mettons le rapport à jour. C’est compris dans le prix, sans surcoût, dans les 90 jours.
Traitement de vos données
Prestataire européen : vos données et vos rapports restent dans l’Union européenne, le RGPD s’applique directement et les intervenants sont nommés au contrat.
Comparaison
Pentest web ou audit de code source ?
Les deux prestations se complètent. Le test d’intrusion éprouve une application en fonctionnement, avec les yeux d’un attaquant ; l’audit de code source trouve les défauts avant la mise en production.
| Critère | Pentest web | Audit de code source |
|---|---|---|
| Objet | L’application en fonctionnement : configuration, comportement et données réelles. | Le code et sa logique, avant même son exécution. |
| Méthode | Tests manuels et exploitation, cas de test OWASP WSTG et ASVS. | Analyse statique outillée, puis relecture manuelle des points sensibles. |
| Moment | Après la mise en production, et après chaque évolution de la surface d’attaque. | De préférence avant le passage en production, dans la chaîne d’intégration. |
| Résultat | Rapport avec impact démontré, preuves et ordre de correction. | Constats au niveau du fichier et de la fonction, avec le correctif proposé. |
| Ce qu’il ne voit pas | Les défauts enfouis dans du code jamais atteint depuis l’extérieur. | Les erreurs de configuration, d’hébergement et d’exploitation. |
Vous hésitez sur la bonne combinaison ? Écrivez-nous ou demandez un devis.
Témoignages clients
Ce que nos clients disent de nous
Pourquoi Haxoris ?
Des prestataires capables de tester une application, il en existe beaucoup en France. La différence se joue sur trois engagements que nous inscrivons dans le devis et que vous pouvez vérifier avant de signer.
Nous ne revendiquons aucune qualification délivrée par l’ANSSI et nous ne soumissionnons pas sur les contrôles réservés.
Contre-audit inclus, sans surcoût
Après correction, nous revenons vérifier. C’est compris dans le prix, dans les 90 jours suivant la remise du rapport, et écrit dans le devis — pas facturé plus tard comme une journée supplémentaire.
Nos tarifs sont publics
Un test d’application web démarre à 2 000 € HT et une mission courante représente 5 à 15 jours-homme. Le détail du calcul figure dans notre article sur le prix d’un test d’intrusion.
Vous savez qui teste
Le pentesteur qui réalise la mission est nommé dans le devis, avec ses certifications (OSCP, OSWE, OSEP) et son ancienneté. C’est lui qui anime la restitution et qui répond à vos développeurs, pas un chargé de compte.
Une méthodologie vérifiable
OWASP WSTG et ASVS pour la couverture, PTES pour le déroulement. Chaque constat du rapport a été exploité à la main avant d’y figurer : aucune sortie de scanner n’est recopiée telle quelle.
Foire aux questions
01 Combien coûte un test d’intrusion sur une application web ?
Le prix suit le périmètre : nombre d’applications, nombre de rôles, nombre d’endpoints d’API, intégrations, et accès ou non au code source. Un test d’application web démarre à 2 000 € HT ; une mission courante représente 5 à 15 jours-homme. Nos tarifs sont publics : le détail figure dans notre article sur le prix d’un test d’intrusion. Après un échange de cadrage d’une trentaine de minutes, vous recevez un devis ferme, sans engagement.
02 Combien de jours-homme faut-il prévoir ?
Une application à deux rôles et une quinzaine d’endpoints tient en 5 à 8 jours-homme. Une plateforme à plusieurs rôles, avec API GraphQL, espace client et intégrations tierces, demande plutôt 10 à 20 jours-homme. Le chiffre est arrêté au cadrage et inscrit dans le devis ; s’il s’avère insuffisant en cours de mission, nous vous le disons avant de consommer le budget, pas après.
03 Boîte noire ou boîte grise ?
La boîte grise dans la grande majorité des cas. Avec un compte par rôle, le même budget couvre davantage de surface et rend testables le contrôle d’accès et la logique métier, c’est-à-dire les défauts que nous trouvons le plus souvent. La boîte noire garde son intérêt pour mesurer l’exposition d’une application publique. La boîte blanche, avec le code source, s’impose sur les applications critiques et les composants de paiement.
04 Le contre-audit est-il inclus ?
Oui, dans le prix et sans surcoût. Après la correction, nous revérifions les constats concernés et mettons le rapport à jour, dans les 90 jours suivant sa remise. Vous obtenez ainsi une version du rapport qui montre l’état après correction : c’est celle que vos clients et vos auditeurs demandent.
05 Faut-il faire appel à un prestataire qualifié ?
Pas pour un test commandé par une entreprise privée. La qualification délivrée par l’ANSSI au titre du décret n° 2015-350 du 27 mars 2015 relève d’une démarche volontaire ; elle n’est pas exigée pour faire tester une application d’entreprise. Haxoris ne détient aucune qualification délivrée par l’ANSSI. En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Nous détaillons ce point dans un article dédié : faut-il un prestataire qualifié pour un test d’intrusion ?
Dernière vérification : 11 septembre 2026.
06 L’application risque-t-elle de tomber pendant le test ?
Non. En production, nous n’exécutons aucun test susceptible d’interrompre le service, et les étapes sensibles sont validées avec vous à l’avance. S’il existe un environnement de recette représentatif, nous y travaillons ; sinon, les tests les plus lourds sont placés dans une fenêtre convenue. Tous nos tests sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal).
07 À quelle fréquence refaire un pentest web ?
Au moins une fois par an, et après chaque évolution qui modifie la surface d’attaque : version majeure, nouvelle API, migration vers le cloud, ouverture d’un espace client, changement d’hébergeur. Le RGPD demande, à l’article 32(1)(d) et lorsque c’est approprié, de tester, analyser et évaluer régulièrement l’efficacité des mesures ; un test annuel suivi d’un contre-audit après correction en est la traduction habituelle.
