Tests d'intrusion avec des résultats validés à la main.
Un test d'intrusion mené par des humains, avec exploitation manuelle et chaque constat reproduit avant d'entrer dans le rapport. L'objectif n'est pas de lister ce qui semble vulnérable : c'est de démontrer ce qu'un attaquant peut faire avec ce que vous exposez aujourd'hui.
Ce qu'un pentest répond et qu'un scanner ne répond pas
Un outil automatique signale ce qui semble vulnérable. Un test d'intrusion démontre ce qui est réellement exploitable et jusqu'où l'accès va. La différence se joue dans l'enchaînement : une faille d'autorisation classée faible isolément devient critique dès qu'elle mène à une donnée que cet utilisateur ne devrait jamais atteindre. Aucun outil ne construit seul ce chemin — et c'est le chemin, pas l'étiquette, qui change la priorité de correction.
- Chaque constat est reproduit à la main avant d'entrer dans le rapport : la sortie brute d'un outil n'est pas un livrable.
- Le risque est décrit par son impact sur votre activité, pas seulement par la note générique d'une base publique.
- Les faux positifs ne vous parviennent pas : ce que nous n'avons pas pu reproduire reste hors du document.
- Le chemin d'exploitation est consigné pas à pas, pour que votre équipe le rejoue et confirme la correction.
What's included
Le périmètre ci-dessous est celui d'une mission type. Tout est ajustable pendant le cadrage, sans frais.
- Authentification, session et récupération de mot de passe
- Autorisation horizontale et verticale par objet
- Injection dans les requêtes, commandes et gabarits
- Logique métier et parcours contournables
- Téléversement, traitement et diffusion de fichiers
- Configuration des en-têtes, cookies et CORS
- Énumération de ressources et identifiants prévisibles
- Contrôle d'accès entre comptes et entre locataires
- Validation de schéma et types inattendus
- Limites de débit, de coût et d'abus automatisé
- Authentification entre services et rotation des secrets
- Exposition excessive de données dans la réponse
- Surface exposée en bordure et services oubliés
- Versions sans support et correctifs en attente
- Cloisonnement entre environnements et entre réseaux
- Services internes atteignables depuis le périmètre
- Configuration TLS et terminaison du trafic
- Déplacement latéral depuis un accès initial
- Fournisseur d'identité et parcours de fédération
- Second facteur : couverture, contournement et récupération
- Privilèges hérités et accumulation de droits
- Comptes de service et identifiants dans le code
- Sessions multi-appareils et révocation
- Inscription et intégration de nouveaux utilisateurs
- Applications Android et iOS, y compris le stockage local
- Communication entre l'app et l'API et épinglage de certificat
- Protection contre l'altération et exécution sur appareil compromis
- Wi-Fi d'entreprise, réseau invité et cloisonnement entre les deux
- Infrastructure sur site et ce qu'elle atteint dans le nuage
- Bornes, terminaux et appareils à usage partagé
- Injection : SQL, NoSQL, LDAP, commandes et gabarits
- Authentification, autorisation, IDOR et élévation de privilèges
- SSRF, XXE et désérialisation non sécurisée
- Failles de logique métier et de parcours de paiement
- XSS, CSRF et détournement de clic à impact démontré
- Cryptographie mal appliquée, jeton prévisible et JWT fragile
Modalities
adjustable to scopeBoîte noire
Nous partons sans information privilégiée, dans la position de qui attaque depuis l'extérieur. Cela mesure ce que votre surface livre à un inconnu et révèle régulièrement des actifs dont personne ne soupçonnait l'exposition.
Boîte grise
Nous recevons des identifiants et une vue d'ensemble de l'architecture. C'est la modalité qui couvre le plus de surface à durée égale, car l'effort va à l'exploitation plutôt qu'à la reconnaissance — et c'est là que les failles d'autorisation apparaissent.
Boîte blanche
Accès au code, à la configuration et à la documentation. Cela permet d'atteindre des chemins rarement visibles de l'extérieur : situations de compétition, gestion des erreurs et logique sensible enfouie sous plusieurs couches.
Quand un pentest change vraiment quelque chose
Ce n'est pas une formalité annuelle. Certains moments font que le test rapporte plus qu'il ne coûte, parce que la surface a changé ou parce que quelqu'un de l'extérieur s'apprête à demander des comptes.
Une réécriture, un nouveau fournisseur d'identité ou une migration déplacent des hypothèses que personne ne réexamine. Tester avant coûte moins cher que le découvrir après, avec du trafic réel par-dessus.
Contrats grands comptes, questionnaires de sécurité et processus d'achat réclament couramment un test indépendant. Le rapport y répond objectivement, sans reposer sur une déclaration interne.
Nouvelle équipe, nouveau service, nouvelle intégration. Une croissance accélérée crée de la surface que personne n'a cartographiée entièrement, et des droits accordés à titre temporaire jamais retirés.
Systèmes internes anciens, interfaces d'administration et intégrations héritées restent hors de tout périmètre pendant des années, précisément parce qu'on les juge trop internes pour inquiéter.
How we conduct it
[pipeline]Définition et règles d'engagement
Avant qu'un seul paquet ne parte, nous consignons par écrit ce qui entre dans le périmètre, ce qui en sort, quelles fenêtres sont autorisées et qui est joint si quelque chose sort du cadre. Nous convenons aussi du critère d'arrêt pour les constats critiques, afin qu'une découverte grave vous parvienne le jour même plutôt qu'avec le rapport.
Reconnaissance et cartographie
Nous établissons la surface réelle : domaines, sous-domaines, services exposés, technologies, points d'entrée et ce qui est déjà public sur l'environnement. C'est l'étape qui fait remonter des actifs absents de l'inventaire : un environnement de recette accessible, une interface oubliée, un service lancé pour un essai et jamais éteint.
Balayage et tri
L'automatisation intervient ici, et seulement ici : elle couvre le volume et propose des candidats. Chaque résultat passe par un tri manuel, car l'essentiel de ce qu'un outil signale ne tient pas quand on tente de le reproduire. Ce qui survit devient une hypothèse d'exploitation.
Exploitation manuelle
C'est là que le test se sépare d'un balayage. Nous enchaînons les failles, sondons la logique métier, tentons l'élévation de privilèges et cherchons à atteindre des données qui devraient être protégées — toujours dans les règles convenues et sans toucher à la disponibilité de la production.
Post-exploitation et portée
Trouver la porte ne suffit pas : ce qui compte, c'est où elle mène. Nous mesurons la portée d'un accès initial, ce qu'il permet de lire, de modifier ou de maintenir, et s'il rend un autre système atteignable. C'est cette mesure qui transforme une note technique en risque métier.
Rapport et contre-test
Le rapport contient le chemin reproductible, l'impact et la correction recommandée, avec la lecture destinée à la direction séparée du détail technique. Après correction, nous retestons les points traités et consignons ce qui est refermé — car un constat corrigé ne compte qu'une fois confirmé.
Références publiques qui encadrent le travail
Nous travaillons sur des méthodologies ouvertes et reconnues. Cela rend le périmètre comparable entre prestataires et permet à votre audit de vérifier la couverture sans nous croire sur parole.
- OWASP WSTG
- Le guide OWASP de test des applications web organise la couverture par catégorie — authentification, session, autorisation, validation, logique métier — et sert de base pour montrer ce qui a été vérifié.
- OWASP API Security
- La liste des risques d'API couvre ce que le test web classique traite mal : autorisation au niveau objet, exposition excessive de données et consommation sans limite.
- PTES
- Le Penetration Testing Execution Standard décrit les phases d'un test, du pré-engagement au rapport, et constitue la colonne vertébrale du déroulé ci-dessus.
- MITRE ATT&CK
- Le catalogue de tactiques et techniques adverses nomme ce qui a été exécuté, ce qui permet à votre équipe de défense de confronter chaque étape à ce que la détection a vu — ou manqué.
- NIST SP 800-115
- Le guide technique du NIST sur l'évaluation de sécurité définit la préparation, l'exécution et l'après-test ; c'est la référence la plus citée dans les exigences contractuelles.
- CVSS
- La notation standardise la gravité technique, mais n'entre qu'en donnée d'entrée : la priorisation suit l'impact dans votre contexte, décrit en clair à côté du chiffre.
Deliverables
dual view · NDASynthèse pour la direction
Une lecture courte pour qui arbitre budget et priorité : ce qui a été testé, ce qui représente un risque réel et ce qui appelle une décision. Écrite sans jargon, pour tenir devant un comité.
Constats avec reproduction complète
Chaque élément porte le chemin pas à pas, avec requête, réponse et preuve. Une personne du développement peut le rejouer sans demander de précision et sans dépendre de qui a mené le test.
Évaluation d'impact et de priorité
Gravité technique et impact métier apparaissent séparément, car ils ne coïncident pas toujours. L'ordre proposé tient compte de l'effort de correction, pour que l'équipe ne commence pas par le plus coûteux et le moins urgent.
Recommandation de correction spécifique
Des conseils appliqués à votre code et à votre architecture, pas un paragraphe générique recopié d'une documentation. Quand plusieurs voies existent, le rapport décrit le compromis de chacune.
Recoupement avec votre supervision
Un récapitulatif de ce qui a été exécuté, cartographié par technique, pour que votre équipe de détection le compare à ce que journaux et alertes ont capté. Cela révèle souvent autant que la liste des vulnérabilités.
Contre-test et lettre de clôture
Après les corrections, nous revoyons les points traités et consignons l'état final. La lettre sert aux clients, partenaires et auditeurs qui ont besoin d'une preuve que le cycle est refermé.
Frequently asked
Par défaut nous ne testons pas la disponibilité. Le déni de service et toute action à risque élevé restent hors périmètre sauf demande explicite avec fenêtre convenue. Si un test peut toucher la production, il est déplacé vers un environnement équivalent ou exécuté dans une fenêtre convenue, avec une ligne directe ouverte du début à la fin.
Un périmètre défini, des identifiants de test pour chaque profil d'utilisateur et un contact technique disponible. Si une protection en bordure risque de bloquer le test, nous décidons ensemble si elle entre dans le périmètre ou reçoit une exception : tester le blocage et tester l'application sont deux objectifs distincts.
Le scan compare ce qu'il trouve à une base connue et renvoie une liste. Le pentest tente l'exploitation, enchaîne les failles et mesure la portée de l'accès. Le scan est peu coûteux et convient au suivi continu ; le test manuel répond à ce que la liste ne dit pas — si l'élément est exploitable dans votre contexte.
Oui. La synthèse est écrite pour un lectorat non technique et peut être partagée avec un client, un partenaire ou un auditeur. Le détail technique figure dans une section distincte, et la lettre de clôture émise après contre-test est le document généralement accepté comme preuve dans un processus d'achat.
Cela dépend du risque. Un environnement de recette fidèle à la production est préférable lorsqu'il existe, car il autorise des tests plus poussés. Quand seule la production existe — le cas le plus courant — nous restreignons les actions destructrices, convenons d'une fenêtre et gardons un canal ouvert pendant toute l'exécution.
Le critère d'arrêt convenu au départ s'applique : un constat critique est signalé immédiatement, avec le minimum nécessaire pour agir, sans attendre le rapport final. Si le cas l'exige, l'exécution est suspendue jusqu'au confinement.
Cela dépend du rythme de changement. Une application en livraison continue change de surface chaque semaine, et un test annuel regarde un système qui n'existe plus. Une pratique répandue associe un test périodique du périmètre principal à un test ponctuel à chaque changement structurel : nouvelle intégration, nouveau fournisseur d'identité, nouvel environnement.
Prêt à découvrir vos failles ?
Premier appel de scoping gratuit et couvert par NDA. En 48 heures vous recevez proposition technique, portée et calendrier. Sans formulaires bureaucratiques.