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. Un référentiel d'exigences d'un côté, un catalogue de tests de l'autre. On va voir comment on plaque concrètement une méthodologie de pentest sur les chapitres du WSTG, comment on vérifie dix contrôles ASVS de niveau 2 pendant une mission, et à quoi ressemble 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.

PHASE DE MISSION            CATEGORIES WSTG          CE QU'ON CHERCHE
-------------------------   ----------------------   ----------------------------
1. Reconnaissance           WSTG-INFO                techno, endpoints, fuites
2. Config & deploiement     WSTG-CONF                en-tetes, methodes, fichiers
3. Comptes & identite       WSTG-IDNT / WSTG-ATHN    enumeration, brute force, MFA
4. Sessions                 WSTG-SESS                fixation, cookies, logout
5. Controle d'acces         WSTG-ATHZ                IDOR/BOLA, elevation, tenants
6. Injection & entrees      WSTG-INPV                SQLi, XSS, SSRF, upload
7. Erreurs & crypto         WSTG-ERRH / WSTG-CRYP    stack traces, TLS, secrets
8. Logique metier           WSTG-BUSL                contournement de workflow
9. Cote client              WSTG-CLNT                DOM XSS, postMessage, CORS
10. API                     WSTG-APIT                autorisation objet, verbes

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.

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, pas une consigne vague. Pour la prochaine mission, le Retest se réduit à revérifier ce contrôle : on sait exactement quoi rejouer et quel résultat attendre. C'est ce qui fait qu'un rapport aligné sur l'ASVS survit à la mission, là où un rapport en prose finit au fond d'un tiroir. 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.
• 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