Test d'intrusion web, mené comme une vraie attaque.
Un test d'intrusion web, ou pentest web, attaque votre application dans les mêmes conditions qu'un adversaire réel, avec votre autorisation écrite et un périmètre défini, pour trouver les failles exploitables avant qu'elles ne le soient contre vous. Nous combinons nos outils maison et une expertise manuelle : beaucoup de failles graves, comme un contrôle d'accès mal fait entre deux comptes, ne se repèrent qu'en comprenant l'application.
En bref
- Le périmètreUne application web en ligne, avec ses comptes, ses parcours et ses back-offices.
- Ce que nous cherchonsDes contrôles d'accès qu'on contourne, une authentification qui cède, des injections et des règles métier qu'on peut détourner.
- Ce qu'il nous fautUn compte par rôle. Le code n'est pas nécessaire.
- Ce que vous recevezUn rapport avec la preuve de chaque faille, une restitution avec votre équipe et un retest sous 60 jours.
Vulnérabilités trouvées dans ces secteurs
- Services publics (.gouv.fr)
- Groupes du CAC 40
- Leaders du luxe
- Médias nationaux
- Mairies et collectivités
Votre application est unique. Vos tests doivent l'être aussi.
Aucun outil ne connaît vos règles métier, vos rôles ni vos parcours. Un attaquant prendra le temps de les apprendre. Nous le faisons avant lui.
Un scanner de vulnérabilités repère une version 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 il ne se demande jamais si l'identifiant 4172 dans une URL peut devenir 4173 pour lire le document du client d'à côté. Il ne remarque pas qu'un rôle « lecture seule » peut appeler l'action de suppression, parce que le bouton a été masqué côté interface mais pas côté serveur.
Une bonne partie des failles de nos rapports sont de ce type.
Avant le correctif
La commande d'un autre client répond 200 : rien ne vérifie à qui elle appartient.
Après le correctif
Le serveur vérifie à qui appartient chaque commande : l'accès à celle d'un autre est refusé.
Le même appel, l'identifiant d'à côté. Retournez la carte pour voir la correction.
Quand faire un test d'intrusion.
Pas une fois pour toutes : aux moments clés de la vie de votre application.
Avant la mise en ligne
Le moment où corriger coûte le moins : rien n'est encore exposé, aucune donnée réelle n'est en jeu.
Après une refonte ou une nouvelle fonctionnalité
Un nouveau parcours, un nouveau rôle ou une intégration ouvrent une surface qui n'a pas encore été testée.
Avant une levée de fonds ou un grand compte
Investisseurs, acheteurs et grands clients demandent de plus en plus la preuve que l'application a été testée.
Une fois par an
Les référentiels comme ISO 27001 ou PCI DSS attendent un test régulier, et votre code change chaque semaine.
Après un incident ou une alerte
Comprendre par où c'est passé, et vérifier qu'aucune autre porte n'est restée ouverte à côté.
Ce que nous testons.
Six familles de vulnérabilités, cherchées à chaque mission, et l'endroit de votre application où chacune se cache.
Contrôles d'accès
Horizontaux et verticaux : Changer un identifiant dans une requête pour atteindre les données d'un autre utilisateur., 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, Un script glissé dans une page et exécuté dans le navigateur de vos visiteurs. 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 fichiers
Exécution de fichiers déposés, traversée de chemin, écrasement de fichiers existants.
Configuration et exposition
Pousser votre serveur à appeler une adresse choisie par l'attaquant, souvent votre réseau interne., La règle qui décide quels autres sites peuvent lire les réponses de votre application depuis un navigateur. trop permissif, sauvegardes accessibles, erreurs bavardes, secrets livrés au navigateur.
Comment se passe une mission.
Six étapes, du cadrage au retest, les mêmes à chaque mission.
Lire la méthodologie complète- 01
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. NDA dès que l'on entre dans le détail technique, convention d'autorisation de test d'intrusion une fois le devis signé, avant tout accès.
- 02
Reconnaissance
Cartographie complète : sous-domaines, points d'entrée, technologies, rôles, flux de données. L'objectif est une carte plus complète que celle de vos propres équipes, parce qu'un attaquant ne se limite pas aux pages du menu de votre site.
- 03
Exploitation
La partie longue. Nos outils maison couvrent la surface. Là où ils ne suffisent plus, nous manipulons les requêtes, changeons les identifiants, sautons ou répétons des étapes de vos parcours et agissons avec les droits d'un autre rôle, jusqu'à un impact démontré.
- 04
Impact & preuve
Une faille n'a d'intérêt que par ce qu'elle permet. Pour chaque trouvaille, nous établissons ce qu'un attaquant obtiendrait réellement, avec une preuve de concept reproductible pas à pas.
- 05
Rapport et restitution
Un rapport classé par gravité réelle, avec l'impact expliqué simplement pour votre direction et des corrections concrètes pour vos développeurs. Puis une restitution en direct avec votre équipe. Voir un exemple de rapport.
- 06
Retest & clôture
Une fois vos correctifs déployés, nous revérifions 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.
Boîte noire, grise ou blanche.
Ce que vous nous donnez au départ décide de ce que le test peut atteindre. Notre conseil, dans presque tous les cas : la boîte grise.
Boîte noire : l'adresse, rien d'autre
- Vous fournissez
- L'adresse de l'application. Aucun compte, aucun code.
- Le test atteint
- Ce que voit un visiteur anonyme : pages publiques, formulaires, API exposées. La connexion arrête le reste, sauf faille pour la franchir.
- À choisir quand
- Vous voulez savoir ce qu'un inconnu peut faire depuis Internet. Les jours passés en reconnaissance réduisent le temps consacré au reste.
Boîte grise : un compte par rôle Notre conseil
- Vous fournissez
- Un compte de test pour chaque rôle : client, gestionnaire, administrateur. Le code reste chez vous.
- Le test atteint
- Tout ce que voit chaque rôle, et surtout ce qu'il ne devrait pas voir. C'est derrière la connexion que se trouvent la plupart de vos données sensibles.
- À choisir quand
- Dans presque tous les cas. C'est le meilleur rapport entre le réalisme d'une attaque et la couverture du test.
Boîte blanche : les comptes et le code
- Vous fournissez
- Les comptes de test, plus un accès au code source et à la documentation.
- Le test atteint
- Aussi les chemins rares que l'interface ne montre jamais, et la logique écrite dans le code.
- À choisir quand
- Sur du code sensible et spécifique, quand la profondeur compte plus que le réalisme.
Ce que ça donne en pratique.
Des failles réelles, toutes corrigées depuis.
rapports envoyés avec une vulnérabilité critique
Sur plus de 485 rapports envoyés, en test d'intrusion et en bug bounty.
rapports envoyés au total
En test d'intrusion et en bug bounty.
Actifs en bug bounty
Chercheurs sur YesWeHack et Intigriti, deux plateformes européennes où chaque faille est vérifiée avant d'être acceptée.
- CritiqueCorrigée
IDOR
Accès aux dossiers complets d'autres usagers sur un service public (.gouv.fr).
- CritiqueCorrigée
Injection SQL
Lecture de l'intégralité de la base de données d'une entreprise.
- ÉlevéeCorrigée
XSS
Prise de contrôle d'un compte utilisateur sans aucune action de la victime.
- ÉlevéeCorrigée
Logique métier
Une étape de validation contournable dans un tunnel de commande : finaliser sans payer.
Nous ne divulguons jamais le nom d'un client, ni aucun détail qui permettrait de le reconnaître.
Le rapport que vous recevez.
Chaque faille prouvée, expliquée et priorisée : un document que votre direction comme vos développeurs peuvent lire et utiliser.
Les dossiers complets d'autres usagers d'un service public, lisibles en changeant un simple identifiant. Des données personnelles exposées : un risque réglementaire et une atteinte à la confiance des usagers.
GravitéCritique, un identifiant changé
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Vérifier côté serveur, à chaque requête, que l'usager connecté a le droit de consulter le dossier demandé, et refuser par défaut.
PrioritéImmédiate, retest inclus
L'intégralité de la base de données d'une entreprise, lisible depuis l'application elle-même, par une requête détournée.
GravitéCritique, base complète
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Remplacer toute requête construite à la main par des requêtes paramétrées, et réduire les droits du compte de base de données au strict nécessaire.
PrioritéImmédiate, retest inclus
Une commande pouvait être finalisée sans payer, en sautant une étape de validation : une perte de revenus directe.
GravitéÉlevée, sans paiement
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Contrôler côté serveur l'enchaînement des étapes, et ne valider une commande qu'après la confirmation du paiement par le prestataire.
PrioritéHaute, retest inclus
Rapport priorisé
Chaque faille de l'application classée par gravité réelle : ce qu'un attaquant obtiendrait vraiment, pas un score théorique.
Preuve de concept reproductible
Les requêtes exactes, que vos développeurs rejouent dans leur propre environnement pour voir la faille de leurs yeux.
Impact métier
Quels comptes, quelles données, quelles commandes sont exposés, dit en clair pour votre direction.
Remédiation concrète
La correction à appliquer côté serveur, expliquée pas à pas pour l'équipe qui maintient l'application.
Retest inclus
Une fois vos correctifs en ligne, chaque faille est rejouée : elle n'est close que lorsque la preuve ne passe plus.
Restitution & échange
Un échange avec vos développeurs pour parcourir les failles, répondre à leurs questions et prioriser les corrections.
Combien ça coûte.
Sur devis, et voici pourquoi : un forfait affiché sans connaître le périmètre serait faux dans les deux sens. Pour vous faire une première idée, voici nos tarifs selon le type de mission.
À partir de2 700 € TTC
Site vitrine ou boutique
Quatre à six jours. Le site public, ses formulaires, son espace client et son tunnel de commande.
À partir de3 200 € TTC
API ciblée
Quatre à huit jours. L'écart vient du nombre d'endpoints sensibles multiplié par le nombre de rôles.
À partir de7 500 € TTC
Application métier ou SaaS
Dix à quinze jours ou plus. Plusieurs rôles, des droits qui se croisent, des parcours complets à franchir.
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.
Ensuite la taille fonctionnelle : un site vitrine n'a rien à voir avec une plateforme à quarante écrans. Puis la présence d'une API, d'un tunnel de paiement, d'un Connexion unique : un seul compte pour entrer dans plusieurs applications, souvent par Google, Microsoft ou Okta. ou d'intégrations tierces, qui ajoutent chacun une surface propre. Enfin la profondeur attendue.
Le premier échange est sans engagement et sert précisément à cadrer tout ça. Si votre besoin est plus léger que prévu, nous vous le dirons.
25vérifications d'accès
Même rôle, autre compteUn rôle sur un autre
Chaque case est une question. Ce rôle peut-il atteindre les données ou les actions de celui-là ? Deux rôles font quatre cases, cinq rôles en font vingt-cinq, et chaque case peut cacher une faille.
Une preuve pour vos audits.
Plusieurs référentiels demandent de tester régulièrement vos mesures de sécurité. Notre rapport est une pièce que vos auditeurs savent lire : périmètre, méthode, preuves et corrections vérifiées.
ISO/IEC 27001
Annexe A, mesures 8.8 et 8.29
Gestion des vulnérabilités techniques et tests de sécurité. Le rapport montre ce qui a été testé, trouvé, puis corrigé.
PCI DSS
Exigence 11.4
Des tests d'intrusion réguliers, et les failles exploitables corrigées. Le retest inclus documente la correction.
SOC 2
Critère CC4.1
Les auditeurs demandent souvent un test d'intrusion récent comme évaluation indépendante de vos contrôles.
RGPD
Article 32
Tester, analyser et évaluer régulièrement l'efficacité des mesures de sécurité. Le rapport en est une trace datée.
NIS 2
Article 21
Évaluer l'efficacité de vos mesures de gestion des risques cyber, gestion des vulnérabilités comprise.
DORA
Articles 24 et 25
Pour les entités financières, un programme de tests de résilience numérique qui inclut les tests d'intrusion.
Nous ne délivrons pas de certification : nous fournissons la preuve technique que vos auditeurs demandent. Notre méthode suit l'Fondation à but non lucratif qui publie les référentiels de sécurité web les plus utilisés, dont le guide de test que nous suivons. Web Security Testing Guide et la structure du Penetration Testing Execution Standard : la trame d'une mission de test d'intrusion, du cadrage au rapport., détaillée ici.
Un test d'intrusion peut-il casser mon site en production ?
Non. Nous travaillons en lecture et en preuve de concept minimale : nous démontrons qu'un accès est possible, nous ne l'exploitons 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 vous 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 la plupart des données sensibles se trouvent 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 passe en général à côté d'un identifiant de commande qui 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.
Boîte noire, grise ou blanche : laquelle choisir ?
La boîte grise dans la quasi-totalité des cas : vous nous donnez un compte de test par rôle, sans accès au code. C'est le meilleur rapport entre le réalisme d'une attaque et la couverture du test. La boîte noire fait perdre des jours en reconnaissance pour un gain de réalisme faible, et la boîte blanche n'a d'intérêt que sur du code sensible et spécifique.
Votre rapport suffit-il pour un audit ISO 27001 ou PCI DSS ?
Il en est une pièce, pas une certification. Le rapport documente le périmètre, la méthode, chaque faille avec sa preuve et sa correction vérifiée au retest : ce que les auditeurs demandent pour les exigences de tests de sécurité, comme l'annexe A de l'ISO 27001 ou l'exigence 11.4 du PCI DSS.
Que se passe-t-il si vous trouvez une faille critique pendant le test ?
Nous vous prévenons le jour même, sans attendre le rapport, avec de quoi comprendre et contenir immédiatement. C'est une règle fixée avant la mission, et c'est la raison pour laquelle nous demandons toujours un contact joignable pendant la fenêtre de test.
Les autres prestations.
Selon ce que vous exposez, une autre mission peut mieux vous convenir.
Audit de sécurité d'API
REST, JSON, GraphQL : ce que chaque endpoint expose vraiment, et à qui.
Voir la prestationAudit de sécurité WordPress
Extensions, thèmes, rôles et surface d'administration laissée ouverte.
Voir la prestationAudit de sécurité de site web
Site vitrine, boutique ou CMS : la sécurité de ce que vos visiteurs voient.
Voir la prestationAuthentification et permissions
IDOR, élévation de privilèges, comptes qui atteignent ce qui ne les regarde pas.
Voir la prestationFaites tester votre application.
Votre application est une cible.
Décrivez-nous le périmètre : ce que fait l'application, combien elle a de rôles, et ce qui vous inquiète. Nous répondons avec un cadrage et un devis. Premier échange sans engagement.