Rédiger la Guidance
Donner aux agents le contexte d'une application : surface d'attaque, priorités, stratégie et techniques interdites, exigences de preuve et conditions d'arrêt, documents OpenAPI ou Postman et comptes de test.
La Guidance est le contexte réutilisable d'une cible. Chaque pentest part de sa version active ; une bonne Guidance donne des tests mieux ciblés et des findings plus utiles.
Prérequis#
- Le domaine de la cible est vérifié : la Guidance reste verrouillée jusque-là.
- Votre rôle permet de modifier la cible (administrateur ou membre).
Les champs#
| Section | Champs | Ce qu'ils attendent |
|---|---|---|
| Surface d'attaque | Contexte de la surface, Éléments hors périmètre | Les parties de l'application et des API qui comptent (authentification, espaces par rôle, uploads, intégrations, webhooks), et ce qui doit rester à l'écart. |
| Priorités | Objectifs prioritaires, Contexte métier | Ce que vous voulez voir testé en premier et ce qui a le plus d'impact pour vous (données clients, paiement, administration). |
| Stratégie d'attaque | Classes de vulnérabilités, Instructions de test, Techniques interdites | Les familles à chercher (contrôle d'accès, injection, logique métier…), les consignes utiles, et ce que les agents ne doivent pas faire (déni de service, suppression de données, envoi de messages ou de paiements réels, accès à des services tiers hors périmètre). |
| Validation | Exigences de preuve, Conditions d'arrêt | Ce qui compte comme une faiblesse démontrée dans votre contexte, et les situations où le test doit s'arrêter. |
Des modèles de départ (SaaS, e-commerce, API, site web public) préremplissent ces champs ; adaptez-les. Aucun champ ne peut rester vide ni ne contenir que des espaces.
Documents d'API#
Joignez vos descriptions OpenAPI, Swagger ou Postman et choisissez celles à inclure dans la prochaine version de Guidance. Elles sont privées, canonisées à l'import et versionnées avec la Guidance. Elles aident les agents à couvrir les API ; elles ne peuvent jamais élargir les URL vérifiées : un chemin qui pointe hors du périmètre autorisé est ignoré.
Supprimer un document ne modifie pas les versions de Guidance déjà publiées.
Comptes de test#
Si l'application exige une authentification, fournissez, au moment de préparer le pentest, des comptes de test dédiés avec les rôles que vous voulez voir exercés. Ils sont chiffrés au repos, matérialisés juste avant l'exécution, expurgés des preuves et purgés ensuite.
Les pentests planifiés (récurrents) ne reçoivent aucun compte de test.
Exclusions et garde-fous#
Les « Éléments hors périmètre » de la Guidance, les exclusions explicites de la cible et les chemins exclus des garde-fous d'un pentest sont des consignes données aux agents ; ils ne constituent pas une politique réseau. Pour un périmètre strictement borné, le pentest externe reste limité aux URL autorisées et le scan interne au mandat. Voir aussi Pendant le test.
Publier#
Publiez la Guidance pour la rendre active. Les versions publiées sont conservées ; un pentest déjà lancé garde la version avec laquelle il est parti. Un pentest planifié se met en pause si la Guidance vient à manquer.
Conseils#
- Décrivez les rôles et ce que chacun doit ou ne doit pas pouvoir faire : c'est la matière première des findings de contrôle d'accès.
- Nommez les flux à fort impact (paiement, export de données, administration).
- Indiquez l'environnement : un environnement de recette isolé évite les effets de bord sur vos données réelles.