La reconnaissance produit facilement beaucoup de données : hôtes, routes, paramètres, technologies et fichiers JavaScript. Pourtant, la quantité ne garantit pas la compréhension. Les vulnérabilités à fort impact apparaissent souvent dans les relations entre ces éléments.
Commencer par le périmètre
Avant toute requête, il faut traduire l’autorisation en règles opérationnelles : domaines inclus, adresses exclues, fenêtres de test, limites de débit et contacts d’urgence. Un actif découvert n’est pas automatiquement un actif autorisé.
Construire une carte, pas une liste
Chaque point d’entrée doit être relié à son rôle :
- Qui peut y accéder et avec quelle identité ?
- Quelles données y entrent et où ressortent-elles ?
- Quel service interne traite la requête ?
- Quelles décisions sont prises côté client et côté serveur ?
- Une autre organisation ou un autre tenant partage-t-il la ressource ?
Cette représentation fait apparaître des scénarios que le scan isolé manque : une route oubliée utilisant un ancien middleware, un objet devinable entre deux tenants ou une intégration qui étend implicitement la confiance.
Les identités avant les payloads
Pour une API moderne, le modèle d’identité est souvent plus important que la technologie. Il faut distinguer utilisateur, organisation, rôle, session, jeton de service et intégration externe. Deux comptes de test appartenant à des espaces séparés permettent de valider proprement l’isolation sans accéder aux données d’un tiers.
Question centrale
Le serveur vérifie-t-il seulement que la requête est authentifiée, ou vérifie-t-il aussi que cette identité possède précisément cet objet et cette action ?
Prioriser par hypothèse
Plutôt que lancer toutes les techniques sur chaque route, on formule des hypothèses : « cette API mobile expose peut-être une version moins contrôlée », « cette intégration transforme une URL en requête serveur », ou « ce changement de rôle repose sur une propriété envoyée par le client ». Chaque test doit confirmer ou invalider une hypothèse.
Conserver une preuve minimale
Une bonne preuve reproduit l’écart avec le moins d’actions possible. Elle contient les préconditions, la requête pertinente, la différence observée, l’impact et une proposition de correction. Les jetons et données personnelles doivent être supprimés avant archivage.
Conclusion
La surface d’attaque utile est un modèle vivant du système. Elle connecte les actifs aux identités et les observations aux impacts, tout en conservant les limites du périmètre autorisé.
Note suivanteDurcissement et chemins d’attaque →