Comment structurez-vous un test d'application web avec l'OWASP WSTG ?
Réponse courte
Le WSTG est une méthodologie adossée à une checklist qui fait passer une application par des catégories de test : collecte d'informations, configuration et déploiement, identité et authentification, autorisation, gestion de session, validation des entrées (injection/XSS), gestion des erreurs, cryptographie, logique métier et côté client. Il offre une couverture systématique avec des identifiants de test stables, de sorte que les constats sont reproductibles et que rien d'évident n'est oublié.
L'OWASP Web Security Testing Guide (WSTG) transforme « teste l'application web » en un processus systématique et reproductible. Les recruteurs s'y réfèrent parce qu'un testeur expérimenté ne tâtonne pas sur des URL au hasard — il parcourt un ensemble structuré de catégories pour que la couverture soit prouvable et que les constats portent des identifiants stables reproductibles par d'autres.
Les catégories de test
Le WSTG organise les tests selon une progression logique :
- Collecte d'informations. Identifier le serveur, les frameworks, les points d'entrée, et cartographier la surface d'attaque de l'application.
- Gestion de la configuration et du déploiement. TLS, en-têtes HTTP, fichiers par défaut, interfaces d'administration, mauvaises configurations cloud et infra.
- Identité et authentification. Énumération de comptes, politiques de mots de passe faibles, contournement de MFA, failles de récupération de mot de passe.
- Autorisation. Élévation de privilèges, références directes d'objet non sécurisées (IDOR), traversée de chemin — l'application impose-t-elle qui peut faire quoi ?
- Gestion de session. Robustesse des jetons, fixation, déconnexion, attributs de cookies.
- Validation des entrées. La famille classique des injections — SQLi, XSS, SSRF, injection de commande.
- Gestion des erreurs et cryptographie. Fuite d'informations, chiffrements faibles, mauvaise gestion des clés.
- Logique métier. Abus de fonctionnalités légitimes — les failles que les scanners ne peuvent pas trouver.
- Côté client. DOM XSS, CORS, postMessage et problèmes JavaScript qui vivent dans le navigateur.
Pourquoi la structure compte
Les catégories imposent une couverture : un scanner trouve un XSS réfléchi mais ne comprend jamais que « sauter l'étape de paiement et obtenir quand même les marchandises » est le vrai bug. Les identifiants de test stables (par ex. WSTG-ATHZ) vous permettent de cartographier les constats, suivre l'avancement et remettre à une équipe de remédiation quelque chose de reproductible.
Ce que recherchent les recruteurs
Ils veulent vous voir mêler automatisation et profondeur manuelle — utiliser le DAST pour dégager l'ampleur, puis consacrer du temps humain à l'autorisation et à la logique métier, les catégories qui exigent réellement un attaquant qui réfléchit.
Questions de suivi probables
- Comment testez-vous les failles de logique métier que les scanners ne peuvent pas trouver ?
- Quelle est la différence entre les tests d'authentification et d'autorisation dans le WSTG ?
- Comment combineriez-vous le WSTG avec du DAST automatisé sans vous noyer dans les faux positifs ?