OWASP ASVS et WSTG : la méthode réelle d'un
pentest web

Quand on parle OWASP, tout le monde pense au Top 10. C'est le document le plus cité et le moins utile en mission : une liste de risques répandus, pratique pour sensibiliser un comité de direction, inexploitable comme procédure de test. Les deux publications de la fondation qu'un pentester ouvre vraiment tous les jours portent des acronymes moins connus : l'ASVS et le WSTG.

L'Application Security Verification Standard (ASVS) dit ce qu'une application doit faire pour être tenue pour sûre. Le Web Security Testing Guide (WSTG) dit comment le vérifier sur une appli qui tourne. Suivent le mapping d'une méthodologie de pentest sur les chapitres du WSTG, la vérification de dix contrôles ASVS de niveau 2 pendant une mission, et un extrait de rapport où une exigence ASVS est citée nommément. Cet article s'inscrit dans le test d'intrusion en entreprise et suppose que vous savez déjà ce qu'est une faille web.

ASVS et WSTG : deux documents, deux usages

L'ASVS 5.0 s'organise en dix-sept chapitres, numérotés de V1 (Encoding and Sanitization) à V17 (WebRTC), en passant par l'authentification (V6), la gestion de session (V7) et l'autorisation (V8). Chaque exigence porte un identifiant chapitre.section.exigence et un niveau. Le standard définit trois niveaux de vérification : le niveau 1 rassemble environ 20 % des exigences, le socle minimal ; le niveau 2, que la plupart des applications devraient viser, porte l'ensemble à près de 70 % ; le niveau 3 ajoute les 30 % restants pour les applications qui exigent la plus forte assurance.

Le WSTG n'a pas la même vocation. Sa version stable, la 4.2, date du 3 décembre 2020 (la 5.0 est en chantier), et elle découpe le test d'une application web en douze catégories, chacune identifiée par un code : WSTG-INFO pour la collecte d'informations, WSTG-ATHN pour l'authentification, WSTG-BUSL pour la logique métier, et ainsi de suite jusqu'à WSTG-APIT pour les API. Là où l'ASVS énonce une propriété à démontrer, le WSTG détaille la manœuvre : quel paramètre trafiquer, quelle réponse observer, quel outil dégainer.

Ni l'un ni l'autre n'est le Top 10 de l'OWASP, qui reste une grille de sensibilisation. Le Top 10 vous dit que le contrôle d'accès cassé est le risque numéro un. Il ne vous dit ni comment le tester (ça, c'est WSTG-ATHZ), ni ce que l'application aurait dû implémenter pour l'éviter (ça, c'est ASVS V8). Confondre les trois, c'est rendre un rapport de pentest qui liste des CWE sans dire comment les vérifier ni comment les corriger.

Cartographier une méthodo de pentest sur les chapitres WSTG

Une mission web ne se déroule pas dans l'ordre du sommaire du WSTG. On la structure en phases, et chaque phase pioche dans une ou plusieurs catégories. Le tableau ci-dessous montre le mapping qu'on applique sur une mission classique, de la reconnaissance à la logique métier.

Trois catégories concentrent l'essentiel des findings graves. Le contrôle d'accès (WSTG-ATHZ) parce que l'IDOR et le BOLA sont partout et ne demandent aucune technicité d'exploitation. La validation d'entrée (WSTG-INPV) parce qu'elle abrite les injections, dont les variantes aveugles qui ne renvoient rien dans la réponse et qu'on ne prouve qu'avec un serveur out-of-band. Et la logique métier (WSTG-BUSL), la seule catégorie qu'aucun scanner ne couvre, parce qu'elle exige de comprendre ce que l'application est censée faire.

Le mapping change avec le mode d'engagement. En blackbox, whitebox ou greybox, on n'attaque pas les mêmes chapitres avec la même profondeur : sans code, la reconnaissance et la configuration pèsent plus lourd ; avec le code, on va directement lire les contrôles d'autorisation. Pour une cible qui expose surtout des endpoints REST ou GraphQL, on bascule le centre de gravité vers WSTG-APIT et la sécurité des API.

Ce qu'un scanner couvre de cette grille : 14 failles sur 27, une sur neuf derrière le login

La tentation, devant douze catégories de tests, est de confier les plus mécaniques à un scanner et de garder le reste pour plus tard. On a mesuré ce que ça donne. Le 7 octobre 2026, sept configurations de scanners (ZAP en mode passif puis actif, Wapiti, nuclei avec ses templates par défaut puis en mode -dast, Nikto et notre propre moteur) ont tourné 600 secondes chacune sur une application PHP volontairement vulnérable de notre banc ptaas-bench, avec un compte client fourni à toutes. L'application porte 27 failles plantées et note elle-même chaque exploitation réussie : un outil n'est crédité que si la faille a réellement produit son effet.

Les treize failles restées sans preuve, rangées dans la catégorie WSTG où un pentester les chercherait, disent assez bien où s'arrête l'automatisation.

Une seule faille derrière le login a été prouvée, une injection de commande dans le dépôt de documents du compte client, et par un seul outil, Wapiti. Pour le reste, avoir une session n'a pas suffi : atteindre la page des factures ne dit pas au scanner lequel de ses paramètres accepte un chemin de fichier, ni quel fichier il faudrait essayer de déposer. C'est le terrain de WSTG-ATHZ et WSTG-BUSL, comme de WSTG-SESS pour la fixation de session, et des exigences ASVS qui leur répondent dans les chapitres V2, V5, V7 et V8 : elles demandent un test guidé par quelqu'un qui connaît l'application. Un scan de dix minutes ne les couvre pas.

Les limites de la mesure sont celles d'un premier banc : une seule application PHP rendue côté serveur, rien sur les applications à page unique ni sur les API, une exécution par outil. Le détail par outil est dans notre article sur le DAST mesuré sur sept configurations, et le tableau faille par faille dans celui sur le pentest automatisé.

Dix contrôles ASVS niveau 2 et comment les vérifier en mission

Le WSTG dit où chercher, l'ASVS dit ce qu'on doit pouvoir cocher. Voici dix exigences de niveau 2, celui que vise la majorité des applications, avec la manœuvre concrète qui permet de conclure conforme ou pas. Les identifiants et les libellés sont ceux de l'ASVS 5.0.0, vérifiés dans le dépôt officiel. Les classiques du contrôle d'accès (l'IDOR/BOLA en 8.2.2, l'application des règles au niveau d'un service de confiance en 8.3.1) sont eux au niveau 1 : on les teste d'office, ils sont le socle.

Deux remarques de terrain. La dernière ligne, 16.3.1, illustre une limite du blackbox : sans accès aux journaux, on ne peut pas prouver qu'une opération est loguée, seulement constater qu'on n'est pas bloqué. Beaucoup d'exigences ASVS de documentation et de journalisation sont dans ce cas, ce qui explique pourquoi le standard note que le niveau 1 lui-même n'est pas entièrement testable par un auditeur externe sans documentation ni code. Et l'exigence 4.1.3 n'est pas un détail académique : un X-Forwarded-For que le client contrôle rend inefficace tout compteur de tentatives, sujet qu'on traite plus largement dans la gestion des vulnérabilités.

Blackbox suit le WSTG, whitebox suit l'ASVS

Le choix du référentiel structurant dépend de ce qu'on a sous la main. En pentest web blackbox, on n'a que l'application qui tourne : le WSTG est la colonne vertébrale naturelle, puisqu'il décrit des tests observables de l'extérieur. On progresse catégorie par catégorie, on note ce qui casse, et on rattache après coup chaque finding à l'exigence ASVS qu'il viole.

En pentest web whitebox, avec le code et la documentation, on inverse la logique : l'ASVS devient la checklist maîtresse. On déroule les chapitres V1 à V17 au niveau visé, on lit les contrôles d'autorisation directement dans le code plutôt que de les deviner à l'aveugle, et on couvre les exigences qu'un blackbox ne peut pas atteindre (journalisation, gestion des secrets, architecture). C'est aussi là que les outils de SAST, DAST et IAST prennent le relais sur les vérifications mécaniques, pour laisser l'humain sur la logique métier et les chaînes d'exploitation.

Citer une exigence ASVS dans un rapport

Un finding rédigé en texte libre se discute : le développeur estime que ce n'est pas grave, le pentester insiste, et le débat s'enlise. Rattaché à un identifiant ASVS, il devient un critère de recette opposable. Voici à quoi ressemble l'en-tête d'un finding tel qu'on l'écrit, avec l'exigence citée explicitement :

[HAUTE] Accès non autorisé aux commandes d'autres clients (BOLA)

Reference    : WSTG-ATHZ-04 (Testing for IDOR)
Non-conformite : ASVS 5.0  8.2.2  (niveau 1)
  "Verify that the application ensures that data-specific access is
   restricted to consumers with explicit permissions to specific data
   items to mitigate insecure direct object reference (IDOR) and broken
   object level authorization (BOLA)."

Constat      : GET /api/v2/orders/{id} renvoie la commande demandee
               quel que soit le compte authentifie. En incrementant {id}
               depuis le compte A, on lit les commandes du compte B
               (nom, adresse, montant).
Impact       : divulgation de donnees personnelles de tous les clients.
Correctif    : filtrer chaque acces objet sur owner_id cote service,
               pas seulement sur la presence d'une session valide.
Retest       : rejouer l'enumeration depuis un compte tiers -> 403 attendu.

Le gain est double. Pour l'équipe de dev, la ligne Correctif et l'identifiant du contrôle donnent une cible nette. Pour la prochaine mission, le Retest se réduit à revérifier ce contrôle : on sait exactement quoi rejouer et quel résultat attendre. Un rapport aligné sur l'ASVS reste donc exploitable après la mission. Le déroulement d'un pentest détaille la place de cette phase de restitution.

À retenir

• ASVS = quoi exiger, WSTG = comment tester. L'ASVS 5.0 liste dix-sept chapitres d'exigences vérifiables sur trois niveaux ; le WSTG 4.2 décrit douze catégories de tests concrets.
• Le Top 10 sensibilise, il ne teste rien et ne spécifie rien. Un pentest sérieux s'appuie sur les deux autres.
• En mission, on structure les phases sur les catégories WSTG ; WSTG-ATHZ, WSTG-INPV et WSTG-BUSL concentrent les findings graves.
• Sur notre banc, sept configurations de scanners réunies prouvent 14 failles sur 27 et une seule des 9 qui demandent d'être connecté : autorisation, session et logique métier restent un travail de pentester.
• Le niveau 2 est la cible de la plupart des applis ; beaucoup de ses exigences (journalisation, en-têtes de confiance) sont plus faciles à prouver en whitebox qu'en blackbox.
• Blackbox suit le WSTG, whitebox suit l'ASVS. Dans les deux cas, on rattache chaque finding à l'identifiant du contrôle violé, avec sa version.
• Un finding qui cite ASVS 5.0 8.2.2 devient un critère de recette : corrigeable, retestable, opposable.

Vous voulez un pentest dont le rapport se lit comme une matrice de conformité ASVS plutôt que comme un roman ? En whitebox, on déroule les chapitres au niveau que vous fixez et on cite l'exigence exacte sur chaque écart : voyez le pentest web whitebox, comparez avec le prix d'un test d'intrusion, ou parlez de votre périmètre via la page contact.

Questions fréquentes sur l'ASVS et le WSTG