Chapitre 1 disponible · Cours en construction. Comprendre le pentest éthique : objectifs, autorisation, périmètre, démarche, preuves et rapport de correction.
Objectifs du chapitre
- Distinguer pentest, audit et analyse de vulnérabilités.
- Définir un périmètre et des règles d’intervention.
- Rédiger un constat utile à la correction.
1. Le pentest : une évaluation encadrée
Un test d’intrusion, ou pentest, évalue la sécurité d’un système en recherchant des chemins d’attaque dans un périmètre convenu. Le but est d’expliquer ce qui pourrait arriver, avec quelles conditions et quel impact, puis d’aider les responsables à corriger. Le mot « éthique » ne décrit pas seulement les intentions : la pratique repose sur une autorisation explicite, une méthode et une gestion prudente des informations.
Un audit examine des règles et des éléments de conformité ; une analyse de vulnérabilités cherche des faiblesses possibles ; un pentest vérifie certains scénarios et leur portée dans les limites de la mission. Ces approches se complètent. Un outil automatique peut signaler une version ancienne sans démontrer que la fonction vulnérable est exposée. Le testeur doit qualifier ce résultat avant de conclure.
Un pentest est limité dans le temps et dans son champ. Une absence de constat ne prouve pas que tout le système est sûr. Les chemins non testés, les comptes disponibles et les restrictions doivent apparaître dans le rapport. Il faut aussi distinguer un test ponctuel d’un programme permanent de gestion des risques.
2. Autorisation et périmètre avant toute action
Dans notre exemple fictif, GeniusCampus souhaite examiner une copie de sa plateforme de formation. Le document de mission identifie le commanditaire compétent, les systèmes autorisés, les dates, les comptes, les contacts et les actions permises. Un serveur portant le même nom, un sous-traitant ou un service de paiement tiers n’entre pas automatiquement dans ce périmètre.
| À fixer | Exemple de décision pour l’atelier |
|---|---|
| Cible | Copie isolée de la plateforme, avec dossiers fictifs. |
| Comptes | Un étudiant fictif, un enseignant fictif et un compte de support limité. |
| Actions | Observation de l’application et vérification de permissions prévue dans le scénario. |
| Limites | Pas de perturbation volontaire, pas de compte réel ni de service tiers. |
| Arrêt | Suspendre en cas de données réelles, de cible inattendue ou de dégradation. |
| Preuves | Conserver uniquement les éléments nécessaires dans un dépôt à accès limité. |
Les règles d’intervention précisent aussi comment signaler une découverte urgente et comment restaurer l’environnement. Tester un système appartenant à une organisation n’autorise pas à collecter toutes les données qu’il contient. Dans ce premier chapitre, le travail est documentaire : aucun scan ni accès à une cible réelle n’est nécessaire.
3. Trois niveaux d’information sur la cible
Un test « boîte noire » fournit peu d’informations initiales. Un test « boîte grise » apporte certains éléments, comme des comptes ou une description partielle. Un test « boîte blanche » donne une visibilité plus importante, par exemple le code ou l’architecture. Ces expressions décrivent des modalités de mission ; aucune n’est supérieure pour tous les objectifs.
Pour vérifier rapidement les permissions d’un portail, des comptes fictifs et une matrice des rôles peuvent être plus utiles qu’une recherche sans contexte. Pour étudier l’exposition publique, le besoin peut être différent. Le choix doit répondre à une question métier, à des contraintes et à un temps disponible, pas seulement reproduire les habitudes d’un outil.
4. De la question au constat
Commencez par une question précise : « Un étudiant peut-il consulter le dossier d’un autre étudiant ? » Le résultat attendu est un refus côté serveur. Préparez deux dossiers fictifs, deux identités et une description de la permission. Réalisez uniquement la vérification autorisée, notez le résultat et distinguez un défaut de sécurité d’une règle métier volontaire.
Un bon constat présente les préconditions, la ressource concernée, le résultat observé, l’impact et la recommandation. Une preuve minimale peut être un extrait anonymisé montrant un accès refusé ou autorisé, avec son heure et le contexte. Elle ne nécessite pas un export complet des dossiers. Les limites doivent être explicites : par exemple, l’atelier n’évalue ni le paiement ni la résistance à une forte charge.
La recommandation doit traiter la cause : vérifier l’autorisation sur l’objet à chaque demande, refuser par défaut et tester plusieurs rôles. « Installer un pare-feu » n’explique pas comment corriger une permission applicative excessive. La criticité dépend de l’exposition, des préconditions et de l’impact, pas seulement du nom de la faille.
5. Rapport et vérification de correction
Le rapport comprend une synthèse compréhensible par le commanditaire et des constats utilisables par l’équipe technique. Chaque constat possède un identifiant, une priorité justifiée, les preuves nécessaires et une proposition de correction. Les sujets non vérifiés restent visibles ; ils ne sont pas décrits comme sûrs.
Après correction, le contre-test vérifie que le scénario initial est refusé tout en conservant l’usage légitime. Dans notre exemple, l’étudiant A ne peut pas consulter le dossier B, mais il peut toujours consulter le sien. La clôture indique la version contrôlée et les limites restantes. Les preuves sont conservées ou supprimées selon les règles de la mission.
Pour préparer la suite, rédigez une fiche de mission et un constat fictif. Nous compléterons le cours avec un laboratoire autorisé, une méthodologie de test et des exercices plus détaillés. Le chapitre de sécurité des applications Web fournit déjà les bases du contrôle d’accès et du traitement des entrées.
Exercices et corrigés
Essayez de répondre avant de déplier les corrigés. Les situations et données sont fictives.
1. Définir le périmètre
Le portail renvoie vers un paiement hébergé chez un prestataire. Ce service est-il automatiquement autorisé pour le pentest ?
Voir le corrigéMasquer le corrigé
Non. La mission doit préciser les services tiers et l’autorité compétente pour les autoriser. On reste dans le périmètre convenu et on signale la dépendance.
2. Qualifier un signalement
Un outil annonce un composant ancien. Peut-on affirmer immédiatement que les dossiers sont accessibles ?
Voir le corrigéMasquer le corrigé
Non. Il faut vérifier la version, les conditions et l’exposition dans les limites autorisées. Un signalement automatique est un point de départ, pas une preuve de l’impact.
3. Écrire un contre-test
Après une correction d’accès aux dossiers, quels deux résultats vérifier ?
Voir le corrigéMasquer le corrigé
L’accès au dossier d’un autre étudiant doit être refusé et l’accès à son propre dossier doit rester possible. Vérifier les deux évite une correction qui bloque tous les usages.
Sources et approfondissements
Sources consultées le 14 octobre 2026. Les cas GeniusCampus et les schémas sont des exemples pédagogiques originaux.
Le cours sera complété progressivement. Le premier chapitre est disponible ; aucun chapitre supplémentaire n’est encore publié.