OWASP WSTG
OWASP WSTG
Le Web Security Testing Guide (WSTG) est le référentiel qui donne sa structure à un test d’intrusion web : ce qui est testé, dans quel ordre, et comment chaque constat est démontré.
Publié et maintenu par la communauté de l’Open Web Application Security Project, le WSTG découpe la surface d’une application en douze catégories, de la collecte d’informations à la logique métier, et détaille plus d’une centaine de cas de test identifiés un par un. Ce n’est pas une liste de cases à cocher : le guide dit quoi vérifier et comment le vérifier, y compris là où un scanner automatisé ne voit rien.
Nos pentesteurs s’appuient sur ce référentiel pour l’ensemble de nos missions applicatives. Il rend un pentest web traçable — vous savez ce qui a été couvert, et ce qui ne l’a pas été — et reproductible d’une campagne à l’autre. Le contre-audit après correction est inclus dans le prix, sans surcoût, et nos tarifs sont publics.
Ils nous font confiance
Le référentiel
Qu’est-ce que l’OWASP WSTG ?
L’OWASP WSTG — Web Security Testing Guide, parfois cherché sous la forme « wstg owasp » — est un manuel ouvert, écrit par des praticiens et versionné comme un projet logiciel. La version stable largement utilisée aujourd’hui est la 4.2 ; une version 5 est en préparation au sein du projet. Le document décrit un cadre de test complet : une phase de reconnaissance passive, puis douze catégories de tests actifs, chacune découpée en cas de test portant un identifiant stable (WSTG-ATHZ-04, WSTG-INPV-05…).
Ce découpage est exactement ce qui le distingue de l’OWASP Top 10. Le Top 10 est un document de sensibilisation : il classe les dix catégories de risques les plus répandues et sert à faire comprendre un enjeu à une direction. Le WSTG est un référentiel d’exécution : il dit comment aller chercher ces risques, et beaucoup d’autres, sur une application donnée. Un rapport qui se réclame du Top 10 décrit des thèmes ; un rapport structuré par le WSTG décrit un périmètre effectivement couvert.
La différence a une conséquence concrète en France. L’article 32, paragraphe 1, point d) du RGPD impose, lorsque c’est approprié, « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». Une procédure, donc : pas un test isolé dont personne ne sait ce qu’il a regardé. Le WSTG fournit précisément cela — une trame stable que l’on rejoue à chaque version majeure de l’application, et dont la couverture se démontre devant un client grand compte, un assureur ou un auditeur ISO 27001.
Il sert enfin de langage commun. Lorsqu’un constat porte un code WSTG, vos développeurs, votre RSSI et notre équipe parlent du même objet, la discussion sur « est-ce vraiment une vulnérabilité ? » se raccourcit, et la vérification après correction ne se négocie pas : on rejoue le cas de test, il passe ou il ne passe pas.
Dernière vérification : 11 septembre 2026.
Objectifs : ce qu’un test conduit selon le WSTG vous apporte
Choisir une méthodologie publique n’est pas un geste décoratif. Cela change ce que vous recevez à la fin, et ce que vous pouvez en faire. Selon le contexte, une mission menée sur cette trame poursuit un ou plusieurs de ces objectifs.
- Obtenir une couverture démontrable : la liste des cas de test joués, et surtout celle des cas écartés avec la raison. C’est la seule façon de répondre honnêtement à la question « qu’avez-vous regardé ? » six mois plus tard.
- Sortir du périmètre des scanners : le contrôle d’accès, la logique métier et l’enchaînement des étapes d’un parcours ne se détectent pas automatiquement. Ce sont aussi les catégories qui produisent nos constats les plus graves.
- Hiérarchiser la correction selon le risque réel dans votre contexte : un score CVSS, mais aussi la donnée atteinte, le nombre de comptes concernés et l’effort d’exploitation.
- Rendre les campagnes comparables : d’un test à l’autre, les mêmes identifiants de cas de test permettent de mesurer une progression plutôt que de repartir d’une page blanche.
- Documenter une procédure de test régulière au sens de l’article 32 du RGPD, et alimenter un dossier de preuves ISO 27001 ou une préparation à la directive (UE) 2022/2555 (NIS 2).
- Donner à vos développeurs de quoi corriger : une requête rejouable, une capture, un correctif proposé et le cas de test à refaire passer.
Le WSTG est une trame applicative. Il s’applique au pentest web et aux API ; pour une infrastructure interne, un environnement cloud ou une opération offensive complète, la trame change — voir nos tests d’intrusion.
Catégories de tests
Les douze catégories de tests du WSTG
Chaque catégorie porte un code et regroupe des cas de test numérotés. Voici ce que nous y cherchons, et les défauts que nous y rencontrons le plus souvent sur des applications françaises de PME et d’ETI.
WSTG-INFO — Collecte d’informations
Nous commençons comme un attaquant commence : empreinte du serveur et des frameworks (WSTG-INFO-02), métafichiers, points d’entrée, contenus laissés en ligne par inadvertance. Cette phase fait presque toujours apparaître un élément absent de votre inventaire — un environnement de recette, une ancienne interface d’administration, un sous-domaine oublié.
WSTG-CONF — Configuration et déploiement
Paramétrage du serveur et de la plateforme applicative, méthodes HTTP autorisées, en-têtes de sécurité, fichiers de sauvegarde et fichiers non référencés (WSTG-CONF-04), interfaces d’administration exposées (WSTG-CONF-05), stockage objet mal protégé et sous-domaines récupérables.
WSTG-IDNT — Gestion des identités
Rôles et habilitations tels qu’ils sont réellement appliqués, procédure d’inscription et de création de compte, énumération d’utilisateurs, comptes de service et comptes de test restés actifs après une mise en production.
WSTG-ATHN — Authentification
Parcours de connexion, politique de mots de passe, authentification multifacteur et, surtout, réinitialisation de mot de passe : il est fréquent qu’un compte soit plus facile à récupérer qu’à forcer. Nous testons aussi les protections contre l’essai automatisé.
WSTG-ATHZ — Autorisation
Contournement du schéma d’autorisation, élévation de privilèges horizontale et verticale, références directes non sécurisées à des objets (IDOR, WSTG-ATHZ-04). C’est la catégorie qui produit nos constats les plus graves sur les applications à comptes clients.
WSTG-SESS — Gestion des sessions
Cycle de vie du jeton de session, attributs des cookies, fixation de session (WSTG-SESS-03), déconnexion effective, expiration côté serveur et falsification de requête intersite (CSRF).
WSTG-INPV — Validation des entrées
Les classiques et leurs variantes : injection SQL (WSTG-INPV-05), Cross-Site Scripting réfléchi et stocké, injection de commandes, injection de gabarit côté serveur et Server-Side Request Forgery (SSRF), particulièrement rentable dès qu’une application tourne dans le cloud.
WSTG-ERRH — Gestion des erreurs
Ce que vos messages d’erreur et vos traces d’exécution racontent à qui les provoque volontairement : versions de composants, chemins internes, requêtes SQL, jetons. Isolément mineur, ce type de fuite raccourcit toujours le travail de l’attaquant suivant.
WSTG-CRYP — Cryptographie
Qualité de la couche de transport (WSTG-CRYP-01), gestion des clés et des certificats, chiffrement au repos, stockage des mots de passe et secrets applicatifs laissés dans un dépôt ou une variable d’environnement.
WSTG-BUSL — Logique métier
Les défauts qui ne violent aucune règle technique mais permettent d’abuser d’une fonctionnalité prévue : un prix modifiable côté client, une remise cumulable indéfiniment, une étape de paiement contournable, un enchaînement d’actions exécuté dans le désordre (WSTG-BUSL-06).
WSTG-CLNT — Côté client
Ce qui s’exécute dans le navigateur : XSS fondé sur le DOM, redirections ouvertes, usage de postMessage, données sensibles en stockage local, politique CORS trop permissive, clickjacking et scripts tiers chargés sans contrôle d’intégrité.
WSTG-APIT — API
API REST et GraphQL (WSTG-APIT-01) : introspection laissée active, autorisation vérifiée au niveau de la ressource mais pas de l’objet, absence de limitation de débit, pagination abusable, et documentation OpenAPI plus permissive que le code qu’elle décrit.
Référentiels
WSTG, OWASP Top 10, ASVS, MASTG, PTES : qui sert à quoi ?
Les acronymes de l’OWASP circulent beaucoup dans les cahiers des charges français, souvent les uns pour les autres. Ils ne répondent pourtant pas à la même question et ne se remplacent pas.
| Référentiel | Ce qu’il est | Comment nous l’utilisons |
|---|---|---|
| OWASP Top 10 | Un classement des dix catégories de risques les plus répandues sur les applications web. Un document de sensibilisation, révisé tous les trois à quatre ans. | Comme grille de lecture dans la synthèse managériale. Jamais comme périmètre de test : dix thèmes ne font pas un plan de test. |
| OWASP WSTG | Le guide d’exécution d’un test d’intrusion web : douze catégories et plus d’une centaine de cas de test identifiés. | Comme trame de toutes nos missions applicatives. Chaque constat du rapport porte le code du cas de test correspondant. |
| OWASP ASVS | Un référentiel d’exigences de sécurité applicative, organisé en niveaux de vérification croissants. | Lorsque la question est « à quel niveau d’exigence cette application doit-elle se conformer ? » plutôt que « jusqu’où peut-on aller ? ». Utile en amont, dans un cahier des charges. |
| OWASP MASTG | L’équivalent du WSTG pour les applications mobiles iOS et Android, associé aux exigences du MASVS. | Sur les missions mobiles, en complément du WSTG lorsque l’application mobile consomme la même API que le site web. |
| PTES | Penetration Testing Execution Standard : une trame de déroulement de mission, du cadrage au rapport, indépendante de la technologie visée. | Pour la conduite de la mission : pré-engagement, collecte de renseignements, modélisation des menaces, exploitation, post-exploitation, restitution. |
En pratique, sur une application web : nous testons selon le WSTG, nous confrontons le résultat aux exigences de l’OWASP ASVS lorsque le contexte l’exige, et nous conduisons la mission selon PTES. Voir aussi notre page OWASP et notre service de pentest web.
Approches : boîte noire, boîte grise, boîte blanche
Le WSTG décrit quoi tester. L’approche décide de ce que nos consultants savent avant de commencer, et donc de la profondeur atteinte pour un même nombre de jours-homme. Les trois approches coexistent sur le marché français ; nous recommandons la deuxième dans la grande majorité des cas.
Boîte noire (black box)
Aucune information préalable : nous partons d’une URL, sans compte ni documentation, comme un attaquant qui ne vous connaît pas. L’approche répond bien à la question « de quoi ai-je l’air vu d’Internet ? » et couvre correctement les catégories WSTG-INFO et WSTG-CONF. Sa limite est mécanique : une part importante du budget passe en reconnaissance, et tout ce qui se trouve derrière l’authentification reste hors de portée. Sur une application à comptes clients, un test en boîte noire laisse structurellement de côté WSTG-ATHZ et WSTG-BUSL, c’est-à-dire la zone où se concentrent les défauts les plus coûteux.
Boîte grise (grey box)
Nous disposons d’un jeu de comptes — un par rôle applicatif — et d’une description fonctionnelle sommaire. C’est l’approche par défaut d’un pentest web et celle que nous proposons sauf raison contraire. Le budget de reconnaissance tombe, les douze catégories du WSTG deviennent toutes atteignables, et le contrôle d’accès entre rôles — le défaut que nous trouvons le plus souvent — devient testable. À nombre de jours égal, la couverture est sans commune mesure avec la boîte noire.
Boîte blanche (white box)
Aux éléments de la boîte grise s’ajoutent le code source, les schémas d’architecture et, le cas échéant, un accès aux journaux. L’approche s’impose sur les applications critiques, les composants de paiement et les traitements de données de santé : elle permet de remonter du symptôme à la ligne fautive et de vérifier des cas de test que l’on ne peut pas provoquer depuis l’extérieur. Elle se combine naturellement avec un audit de code source.
Une précision de vocabulaire, parce qu’elle revient dans les appels d’offres : on dit un test en boîte noire, en boîte grise, en boîte blanche. L’approche se décide au cadrage et figure dans le devis, avec les comptes et les accès que vous vous engagez à fournir.
Périmètre et cadrage
Le WSTG ne fixe pas votre périmètre : il le rend chiffrable. Un cadrage d’une trentaine de minutes suffit le plus souvent à transformer une demande vague en un nombre de jours-homme défendable. Les éléments qui pèsent réellement :
- Le nombre de rôles applicatifs. C’est le premier facteur de coût, bien avant le nombre de pages : chaque rôle supplémentaire multiplie les combinaisons à éprouver dans WSTG-ATHZ.
- La surface d’API. Nombre d’endpoints REST, présence d’un schéma GraphQL, webhooks, intégrations tierces. Une documentation OpenAPI à jour réduit le temps de reconnaissance et le prix.
- La richesse fonctionnelle. Paiement, import et export de fichiers, génération de documents, moteur de règles, espace d’administration : ce sont les fonctions qui alimentent WSTG-BUSL.
- L’environnement de test. Une recette représentative autorise des tests que la production interdit. À défaut, nous travaillons en production avec des règles d’engagement écrites et une fenêtre convenue.
- L’accès au code source, s’il est envisagé, et les composants explicitement exclus (services d’un hébergeur tiers, briques SaaS que vous ne maîtrisez pas).
Le cadrage produit une note de cadrage écrite : périmètre, approche retenue, catégories WSTG couvertes, comptes à fournir, fenêtre d’intervention, contacts d’escalade, nombre de jours-homme et prix ferme en € HT. Rien ne démarre avant sa validation. Tous nos tests sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal).
Notre méthodologie
Notre méthodologie et le déroulement d’une mission
La mission se conduit selon PTES, les tests applicatifs suivent l’OWASP WSTG, les exigences se lisent au regard de l’OWASP ASVS et les applications mobiles relèvent de l’OWASP MASTG. L’outillage — Burp Suite en tête — sert à accélérer la reconnaissance et à couvrir les cas répétitifs ; les catégories WSTG-ATHZ, WSTG-BUSL et WSTG-APIT sont traitées à la main, faute de quoi elles ne sont pas traitées du tout.
Cadrage et note de cadrage
Nous définissons ensemble le périmètre, les rôles, les scénarios de menace pertinents et l’approche (boîte noire, grise ou blanche). Vous recevez une note de cadrage écrite avec les jours-homme et un prix ferme en € HT, puis le mandat à signer.
Reconnaissance et cartographie
Catégorie WSTG-INFO : empreinte des composants, cartographie des points d’entrée, des rôles et des flux de données. Nous produisons la liste des cas de test retenus — et celle des cas écartés, avec la raison. Vous la validez avant les tests actifs.
Tests actifs, catégorie par catégorie
Nous parcourons les douze catégories du WSTG dans l’ordre, en adaptant la profondeur au périmètre : configuration, identités, authentification, autorisation, sessions, validation des entrées, erreurs, cryptographie, logique métier, côté client et API.
Exploitation et preuves
Chaque constat est démontré : requête rejouable, capture, chaîne d’exploitation lorsqu’elle existe. Aucun test susceptible d’interrompre le service n’est exécuté en production sans votre accord préalable. Un point d’avancement vous est adressé chaque jour, et toute vulnérabilité critique vous est signalée immédiatement.
Rapport et restitution
Le rapport est rédigé en français. Les constats sont classés par code WSTG, notés en CVSS, replacés dans votre contexte et accompagnés d’un correctif proposé. La restitution se tient en visioconférence, avec vos développeurs autant qu’avec votre direction, et l’enregistrement reste à votre disposition.
Contre-audit après correction
Une fois vos correctifs déployés, nous rejouons les cas de test concernés et mettons le rapport à jour. Ce contre-audit est inclus dans le prix, sans surcoût, dans les 90 jours suivant la remise du rapport.
Livrables
Livrables, restitution et contre-audit
Un test n’a d’intérêt que par ce qu’il permet de corriger. Nos livrables sont conçus pour être utilisables dès la semaine suivante, par vos équipes comme par vos interlocuteurs externes.
Synthèse managériale
Quelques pages sans jargon pour votre direction ou votre comité : niveau de risque, scénarios les plus plausibles, effort de correction estimé et décisions à prendre.
Rapport technique détaillé
Chaque constat avec son code WSTG, son score CVSS, la preuve d’exploitation, les étapes de reproduction et le correctif proposé. Rédigé en français, y compris les recommandations.
Tableau de couverture WSTG
La liste des catégories et des cas de test joués, et de ceux qui ont été écartés avec la raison. C’est la pièce que réclament les auditeurs et les clients grands comptes.
Export pour vos développeurs
Les constats au format CSV ou JSON, à importer dans Jira, Azure DevOps ou votre outil de suivi, avec la priorité déjà renseignée.
Restitution en visioconférence
Une session de travail avec l’équipe qui a testé — pas un commercial. Vos développeurs posent leurs questions à la personne qui a écrit le constat.
Contre-audit inclus, sans surcoût
Après correction, nous rejouons les cas de test concernés et éditons une version du rapport qui atteste l’état après remédiation, dans les 90 jours suivant sa remise.
Pourquoi Haxoris
Contre-audit inclus, sans surcoût
La vérification après correction fait partie du prix, dans les 90 jours suivant la remise du rapport. Vous repartez avec un rapport qui montre l’état après remédiation.
Nos tarifs sont publics
Le nombre de jours-homme et le prix en € HT sont annoncés avant la commande. Un test d’application web démarre autour de 2 000 € HT.
Vous savez qui teste
Les consultants affectés à votre mission sont nommés au devis, avec leurs certifications (OSCP, OSWE, CISSP). Vous leur parlez directement, du cadrage à la restitution.
Prestataire européen
Haxoris est une société établie dans l’Union européenne. Les éléments collectés pendant le test sont chiffrés, conservés dans l’Union et supprimés à l’échéance prévue au contrat, sans transfert hors UE à encadrer.
Témoignages clients
Ce que nos clients disent de nous
Foire aux questions
01 Qu’est-ce que l’OWASP WSTG ?
Le Web Security Testing Guide est le guide de test de sécurité applicative publié par l’Open Web Application Security Project. Il décrit un cadre complet de test d’intrusion web : une phase de reconnaissance, puis douze catégories de tests actifs découpées en plus d’une centaine de cas de test identifiés. C’est une méthodologie d’exécution, librement consultable, révisée par la communauté et utilisée comme référence commune par la plupart des prestataires.
02 Quelle différence entre le WSTG et l’OWASP Top 10 ?
Le Top 10 classe les dix catégories de risques les plus répandues : c’est un document de sensibilisation, utile pour expliquer un enjeu à une direction. Le WSTG explique comment aller chercher ces risques, et beaucoup d’autres, sur une application réelle. Un prestataire qui annonce « un test OWASP Top 10 » annonce un thème ; un prestataire qui annonce un test WSTG annonce un périmètre de cas de test, que vous pouvez lui demander de détailler.
03 Combien coûte un test d’intrusion mené selon le WSTG ?
Le prix suit le périmètre : nombre de rôles, nombre d’endpoints d’API, richesse fonctionnelle, accès ou non au code source. Un test d’application web démarre autour de 2 000 € HT. Nos tarifs sont publics et le détail figure dans notre article sur le prix d’un test d’intrusion. Après un cadrage d’une trentaine de minutes, vous recevez un devis ferme, sans engagement.
04 Combien de jours-homme faut-il prévoir ?
Une application à deux rôles et une quinzaine d’endpoints tient généralement en 5 à 8 jours-homme. Une plateforme à plusieurs rôles, avec API GraphQL, espace client et intégrations tierces, demande plutôt 10 à 20 jours-homme. Couvrir les douze catégories du WSTG en profondeur sur un périmètre large prend du temps : c’est précisément pourquoi la liste des cas retenus et des cas écartés vous est soumise avant les tests actifs, plutôt que découverte à la lecture du rapport.
05 Boîte noire ou boîte grise ?
La boîte grise dans la grande majorité des cas. Avec un compte par rôle, le même budget couvre davantage de surface et rend testables le contrôle d’accès (WSTG-ATHZ) et la logique métier (WSTG-BUSL), c’est-à-dire les catégories qui produisent nos constats les plus graves. La boîte noire garde son intérêt pour mesurer l’exposition d’une application publique. La boîte blanche, avec le code source, s’impose sur les applications critiques et les composants de paiement.
06 Le contre-audit est-il inclus ?
Oui, dans le prix et sans surcoût. Après vos correctifs, nous rejouons les cas de test concernés et mettons le rapport à jour, dans les 90 jours suivant sa remise. Vous obtenez ainsi une version du rapport qui atteste l’état après remédiation : c’est celle que réclament vos clients, vos assureurs et vos auditeurs.
07 Faut-il faire appel à un prestataire qualifié ?
Pas pour un test commandé par une entreprise privée. La qualification délivrée par l’ANSSI au titre du décret n° 2015-350 du 27 mars 2015 relève d’une démarche volontaire ; elle n’est pas exigée pour faire tester une application d’entreprise. Haxoris ne détient aucune qualification délivrée par l’ANSSI. En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Nous détaillons ce point dans un article dédié : faut-il un prestataire qualifié pour un test d’intrusion ?
08 Le WSTG couvre-t-il les API et les applications mobiles ?
Les API, oui : la catégorie WSTG-APIT leur est consacrée et les autres catégories s’y appliquent directement, une API n’étant qu’une surface d’application sans interface. Pour le mobile, l’OWASP publie un guide distinct, le MASTG, accompagné des exigences du MASVS : nous l’employons sur nos missions de pentest mobile, en gardant le WSTG pour l’API partagée avec le site web.
09 À quelle fréquence refaire un test ?
Au moins une fois par an, et après chaque évolution qui modifie la surface d’attaque : version majeure, nouvelle API, migration vers le cloud, ouverture d’un espace client, changement d’hébergeur. L’article 32, paragraphe 1, point d) du RGPD demande, lorsque c’est approprié, de tester, analyser et évaluer régulièrement l’efficacité des mesures : un test annuel suivi d’un contre-audit après correction en est la traduction habituelle. Dernière vérification : 11 septembre 2026.
