Un bon pentest commence avant le premier test. La qualité du cadrage détermine ce qui pourra être évalué, le niveau de réalisme des scénarios et la valeur du rapport final.
1. Définir l’objectif métier
« Tester l’application » est trop vague. L’objectif doit expliquer la décision que l’évaluation doit éclairer : mise en production, audit client, évolution d’architecture, nouvelle API partenaire ou mesure du risque sur un parcours critique.
Identifiez les flux qui méritent une attention particulière : inscription, authentification, récupération de compte, paiement, administration, import/export, invitations et séparation entre organisations.
2. Construire un périmètre vérifiable
Le périmètre doit lister les domaines, API, applications mobiles associées, rôles utilisateurs et dépendances autorisées. Précisez les environnements exclus, les fournisseurs tiers et les actions interdites.
Pour une application multi-tenant, fournissez au moins deux organisations de test et plusieurs rôles. Sans cette séparation, les contrôles d’accès objet et les changements de contexte restent difficiles à valider correctement.
3. Préparer les accès et les données
Créez des comptes dédiés au pentest. Ils doivent couvrir les rôles réels sans réutiliser de comptes personnels. Préparez des données fictives représentatives, les procédures MFA, les clés API temporaires et un canal sûr pour transmettre les secrets.
Documentez aussi les mécanismes susceptibles de bloquer l’évaluation : WAF, rate limiting, allowlist IP, anti-bot, liens magiques et intégrations asynchrones.
4. Encadrer les tests actifs
Définissez les fenêtres de test, les contacts d’urgence, les limites de charge et la procédure d’arrêt. Décidez explicitement si les scénarios destructifs, l’ingénierie sociale, les fournisseurs ou la production sont exclus.
Une autorisation claire protège les deux parties et évite de remplacer les tests utiles par des hypothèses prudentes.
5. Préparer la remédiation dès le départ
N’attendez pas le rapport pour identifier les responsables. Associez les équipes produit, développement, infrastructure et sécurité au débrief. Convenez du format des preuves, du système de criticité et des modalités de retest.
Un livrable utile doit distinguer le symptôme, la cause, le chemin d’exploitation, l’impact métier et la recommandation. Il doit permettre à une équipe qui n’a pas réalisé le test de reproduire et corriger le constat.
Checklist avant démarrage
- Objectif et actifs autorisés validés
- Rôles et organisations de test disponibles
- Secrets transmis par un canal adapté
- Exclusions et limites de charge documentées
- Contacts d’urgence joignables
- Journalisation et sauvegardes vérifiées
- Propriétaires de remédiation identifiés
- Retest et critères de clôture convenus
Ce travail de préparation ne réduit pas la profondeur du pentest. Il libère du temps pour tester les scénarios qui comptent réellement.