Une bonne méthodologie de test d’intrusion commence avant la première requête et se termine après le rapport. Elle permet de tester de façon autorisée, de produire des preuves utiles et de vérifier les corrections.

1. Définir le périmètre et l’autorisation

L’entreprise identifie les applications, API, environnements, comptes et périodes de test. Elle précise également ce qui est exclu : systèmes tiers, données sensibles, actions destructrices ou plages de forte activité. L’autorisation doit venir d’une personne habilitée et être documentée.

Cette étape protège les équipes et améliore le résultat. Sans périmètre clair, un test peut être trop timide sur un actif critique ou trop intrusif sur un service qui ne devait pas être concerné.

2. Comprendre la surface d’attaque

Le testeur cartographie les points d’entrée autorisés et les relations entre utilisateurs, rôles, ressources et API. Pour une application web, cela inclut les parcours de connexion, d’administration et de partage de données.

Le but n’est pas d’accumuler des URL. Il est de repérer les chemins qui permettraient d’atteindre un actif important ou de franchir une frontière entre comptes.

3. Identifier les hypothèses de vulnérabilité

Les outils et l’analyse humaine relèvent des signaux : configuration, composants, autorisations, sessions, logique métier. Chaque signal devient une hypothèse à examiner. Une alerte de scanner reste une hypothèse tant que son impact dans le contexte du produit n’est pas établi.

4. Valider de manière contrôlée

La validation utilise des comptes et des données prévus pour le test. Elle doit démontrer le problème sans perturber le service. Une requête, une réponse et le contexte du compte peuvent constituer une preuve reproductible. Les limites convenues au cadrage restent applicables.

5. Restituer les résultats

Un rapport utile présente les constats confirmés, leur impact, les étapes de reproduction et une recommandation technique. Il explique aussi ce qui a été testé et ce qui ne l’a pas été. La priorisation doit tenir compte de l’exposition et de la valeur des données concernées.

Voir le périmètre de l’évaluation technique Web & API.

6. Retester après correction

Après la modification du code ou de la configuration, le scénario initial est rejoué. Le résultat indique si le chemin est fermé dans la version examinée. La preuve de fermeture complète le constat initial ; elle ne suppose pas que tous les autres chemins sont également sûrs.

Ces étapes constituent une méthode, pas une durée ou une garantie universelle. Le détail dépend de l’application et de l’engagement. Pour une équipe qui livre fréquemment, une validation continue peut maintenir cette logique de preuve et de retest dans le temps.

Cadrer un test d’intrusion avec HEXBOX