OWASP ASVS
OWASP ASVS
L’Application Security Verification Standard est le référentiel de l’OWASP qui décrit, exigence par exigence, ce qu’une application web ou mobile doit satisfaire pour être considérée comme sûre. Nous l’utilisons comme grille de vérification : dans notre rapport, chaque constat porte le numéro de l’exigence qu’il met en défaut, et non une appréciation générale.
Trois niveaux — ASVS niveau 1, niveau 2 et niveau 3 — permettent d’ajuster la profondeur du test au risque réel porté par votre application. Nous vous aidons à choisir le bon, puis nous testons contre lui, et le contre-audit est compris dans le prix.
Ils nous font confiance
Objectifs
Objectifs d’une vérification ASVS
Espérer qu’une application est sûre n’est pas une mesure de sécurité. L’ASVS transforme cette espérance en question vérifiable : le référentiel énumère plusieurs centaines d’exigences testables, regroupées par domaine, et le travail consiste à établir, pour chacune, si votre application la satisfait, ne la satisfait pas, ou si elle est sans objet dans votre contexte — cette dernière décision étant elle aussi écrite et justifiée.
L’objectif n’est donc pas de produire la plus longue liste de vulnérabilités possible. Il est de répondre aux trois questions que se posent une direction technique et un RSSI : où en sommes-nous, par rapport à quel référentiel, et qu’est-ce qui a changé depuis la dernière campagne ? Un test cadré par un standard répond aux trois. Un test libre ne répond qu’à la première, et son résultat n’est comparable ni à celui de l’an dernier, ni à celui d’un autre prestataire.
Nous vérifions ainsi des mesures concrètes plutôt que des thèmes généraux : authentification, gestion des sessions, contrôle d’accès, validation des entrées, cryptographie, gestion des secrets, journalisation, traitement des données à caractère personnel. Le rapport n’est pas seulement une liste de failles, c’est aussi un ordre de passage : ce qui se corrige maintenant, ce qui attend le prochain sprint, ce que vous assumez sciemment et pour quelle raison.
C’est également ce que demande le RGPD. L’article 32.1.d impose, le cas échéant, « 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 vérification périodique menée à un niveau ASVS fixé est précisément une telle procédure, et elle se démontre bien mieux qu’un test ponctuel sans référentiel. Dernière vérification du cadre juridique cité : 11 septembre 2026.
Niveaux ASVS
Niveaux ASVS : 1, 2 ou 3 ?
Le référentiel est gradué. Chaque niveau reprend l’intégralité du précédent et ajoute des exigences plus strictes. Le choix se fait sur le risque porté par l’application — la nature des données traitées et les conséquences d’une compromission — et non sur la taille de l’entreprise ou le nombre d’écrans.
| Critère | ASVS niveau 1 | ASVS niveau 2 | ASVS niveau 3 |
|---|---|---|---|
| Pour quelles applications | Applications à faible risque, sans donnée sensible ni transaction financière. | Applications traitant des données à caractère personnel (RGPD) ou des données métier sensibles. Le choix le plus fréquent. | Applications à risque élevé : banque et assurance, santé, énergie, téléservices publics. |
| Objectif du test | Écarter les vulnérabilités faciles à exploiter et massivement automatisées. | Résister à un attaquant motivé qui cible spécifiquement votre application. | Résister à un attaquant disposant de temps, de moyens et d’une connaissance interne du système. |
| Exemples | Site vitrine, page de campagne, blog d’entreprise. | Site e-commerce, extranet client, plateforme SaaS, CRM, portail RH. | Banque en ligne, dossier patient informatisé, application de paiement, téléservice public. |
| Approche associée | Boîte noire ou boîte grise. | Boîte grise, avec un compte applicatif pour chaque rôle. | Boîte blanche, avec accès au code source et aux schémas d’architecture. |
| Cadre de référence | Hygiène de sécurité de base. | RGPD article 32, PCI DSS, préparation à la directive (UE) 2022/2555 (NIS 2). | Exigences sectorielles strictes, dont le règlement (UE) 2022/2554 (DORA) pour les entités financières. |
| Charge indicative | 5 à 8 jours-homme. | 8 à 15 jours-homme. | 15 à 25 jours-homme, davantage sur une application complexe. |
Vous hésitez entre deux niveaux ? Nous cadrons le risque avec vous en une trentaine de minutes, puis nous vous recommandons un niveau, une approche et un périmètre — avant tout devis, et sans engagement.
Périmètre technique
Ce que le référentiel ASVS vérifie
Les exigences sont regroupées par chapitre. Voici les domaines que nous reprenons systématiquement sur une application web, dans le cadre d’un test d’intrusion applicatif. Sur une application mobile, ils se complètent des chapitres propres au MASTG.
Authentification
Robustesse et stockage des mots de passe, second facteur, parcours de réinitialisation, verrouillage après échecs, fédération d’identité et mise en œuvre d’OAuth 2.0 et d’OpenID Connect.
Gestion des sessions
Génération et rotation des jetons, expiration côté serveur, déconnexion réellement effective, portée et attributs des cookies, gestion des sessions concurrentes.
Contrôle d’accès
Cloisonnement entre rôles, cloisonnement entre clients d’une plateforme mutualisée, références directes à des objets : la famille de failles que les outils automatiques ne détectent pas.
Validation des entrées et encodage
Injections SQL et NoSQL, XSS, désérialisation non sûre, traversée de chemin, injections de commandes et de modèles, traitement des fichiers téléversés.
Cryptographie et secrets
Algorithmes et longueurs de clés, qualité de l’aléa, empreintes de mots de passe, rotation et stockage des clés, secrets laissés dans le code ou les variables d’environnement.
API et services
REST, GraphQL et WebSocket : authentification des appels, limitation de débit, exposition de champs non prévus, documentation d’API laissée accessible en production.
Données et vie privée
Minimisation, chiffrement au repos et en transit, durées de conservation, fuites par les journaux, les messages d’erreur, les exports et les caches.
Journalisation et erreurs
Ce qui doit être tracé, ce qui ne doit jamais l’être, et la capacité concrète à reconstituer un enchaînement d’actions après un incident.
Configuration et architecture
En-têtes de sécurité, durcissement des composants, dépendances tierces et versions obsolètes, chaîne de construction, secrets embarqués dans les images.
Approches
Approches : boîte noire, boîte grise, boîte blanche
Le niveau ASVS dit à quelle profondeur vérifier. L’approche dit avec quelles informations nous travaillons. Les deux se décident ensemble, au cadrage, et se combinent sans difficulté sur une même mission.
Boîte noire (black box)
Nous partons de ce dont dispose un attaquant extérieur : une URL, rien d’autre. Aucun compte, aucune documentation, aucun accès au code. C’est la simulation la plus fidèle d’une attaque opportuniste, et c’est aussi la moins rentable en couverture : le temps passé à deviner ce qui existe n’est pas passé à tester. Pertinente pour un niveau 1, ou pour mesurer la surface réellement exposée avant une campagne plus profonde.
Boîte grise (grey box)
Nous disposons d’un compte applicatif pour chaque rôle et d’une présentation fonctionnelle de l’application. C’est l’approche par défaut d’une vérification ASVS niveau 2, et la seule façon sérieuse de contrôler les autorisations : sans deux comptes de rôles différents, personne ne peut démontrer qu’un utilisateur n’accède pas aux données d’un autre. C’est le meilleur rapport couverture/budget dans la grande majorité des cas.
Boîte blanche (white box)
Nous ajoutons le code source, les schémas d’architecture, la configuration et, lorsque c’est utile, des échanges directs avec vos développeurs. Une partie des exigences de niveau 3 — qualité de l’aléa, gestion des clés, vérifications réellement effectuées côté serveur — ne peut être attestée autrement que par lecture du code. C’est l’approche imposée par le niveau 3.
Une idée fausse circule souvent : la boîte noire serait plus réaliste, donc meilleure. Elle est effectivement plus réaliste, et nettement moins utile. Un attaquant dispose de semaines ; votre prestataire dispose de jours. Chaque information transmise au départ est du budget rendu au test lui-même.
Cadrage
Périmètre et cadrage
Le périmètre s’écrit avant le premier paquet envoyé. Nous listons nominativement les domaines, sous-domaines, URL et points d’entrée d’API concernés, les rôles applicatifs à couvrir, les fonctions critiques à ne pas manquer, et ce qui est explicitement hors périmètre : un hébergeur, un service tiers, une intégration dont vous n’êtes pas propriétaire.
Ce que nous vous demandons tient en quatre points : une autorisation écrite signée par une personne pouvant engager l’entité propriétaire du système ; un environnement de recette fidèle à la production, ou une fenêtre convenue sur la production ; un compte de test par rôle applicatif ; un contact technique joignable pendant toute la campagne. Nous ne testons rien en dehors de ce cadre.
Les données auxquelles nous accédons pendant la mission sont traitées en qualité de sous-traitant au sens de l’article 28 du RGPD. Haxoris OÜ est une société établie dans l’Union européenne : les données et les rapports restent dans l’UE, aucun transfert hors UE n’est nécessaire à la réalisation de la prestation, et les éléments collectés sont supprimés à l’échéance de conservation prévue au contrat.
Notre méthodologie
Notre méthodologie et le déroulement d’une vérification ASVS
L’ASVS dit quoi vérifier ; il ne dit pas comment. Pour le comment, nous nous appuyons sur les guides d’exécution de l’OWASP — le WSTG pour le web, le MASTG pour les applications mobiles — et sur le PTES pour la conduite générale de la mission, du cadrage à la restitution. L’ensemble est reproductible : la même application testée deux fois au même niveau produit les mêmes constats.
Cadrage et choix du niveau (scoping)
Nous analysons ensemble ce que fait l’application, qui l’utilise et quelles données elle traite. Il en découle le niveau — 1, 2 ou 3 —, l’approche — boîte noire, grise ou blanche —, le périmètre nominatif et la charge en jours-homme. Le devis est établi à ce moment-là, à prix ferme, et rien ne démarre sans autorisation écrite.
Rattachement des exigences à votre application
Les exigences du niveau retenu sont mises en regard de vos fonctions réelles : connexion, réinitialisation de mot de passe, paiement, export de données, téléversement de fichiers, appels d’API entre services. Les exigences sans objet dans votre contexte sont écartées explicitement, et cette décision figure au rapport : personne ne découvre après coup qu’un domaine entier n’a pas été regardé.
Reconnaissance et cartographie
Énumération des points d’entrée, des technologies, des rôles et des flux de données, selon les phases du PTES. Cette étape produit la carte contre laquelle les tests seront menés, et révèle souvent à elle seule des éléments oubliés en production : préproduction accessible, ancienne version d’API toujours servie, interface d’administration exposée.
Tests manuels, outillés là où c’est utile
L’outillage sert à couvrir le volume : dépendances obsolètes, en-têtes manquants, certificats, erreurs de configuration connues. Les exigences qui font la différence — contrôle d’accès entre rôles, logique métier, enchaînement de vulnérabilités mineures en scénario réellement exploitable — se vérifient à la main, selon le WSTG et le MASTG. Aucune exigence n’est déclarée satisfaite sur la seule foi d’un scanner.
Rapport, preuves et restitution
Chaque constat porte le numéro de l’exigence ASVS concernée, une description, une criticité argumentée, la preuve d’exploitation (capture, requête, extrait de code) et une correction concrète écrite pour vos développeurs. La restitution se tient en visioconférence, en français, avec l’équipe technique et le commanditaire ; les constats critiques, eux, vous sont signalés au fil de l’eau et non à la remise du rapport.
Contre-audit inclus
Après la mise en œuvre de vos correctifs, nous procédons au contre-audit sans surcoût, dans les 90 jours suivant la remise du rapport. Vous recevez un rapport de contre-audit distinct qui indique, exigence par exigence, ce qui est effectivement corrigé, ce qui ne l’est que partiellement, et ce qui reste ouvert.
Livrables
Livrables et restitution
Synthèse pour la direction
Trois pages sans jargon : niveau visé, niveau atteint, décisions à prendre.
Rapport technique en français
Chaque constat rattaché à son exigence ASVS, avec la preuve d’exploitation.
Matrice de couverture ASVS
Exigence par exigence : satisfaite, non satisfaite ou sans objet — et pourquoi.
Plan de remédiation priorisé
Classé par risque réel et par effort de correction, pas par criticité théorique.
Export Jira ou Azure DevOps
Pour que les constats entrent directement dans votre cycle de développement.
Contre-audit inclus
Un second passage sans surcoût sous 90 jours, avec son propre rapport.
Pourquoi Haxoris
Contre-audit inclus, sans surcoût
Le second passage après correction est compris dans le prix, sous 90 jours. Ce n’est pas une journée supplémentaire facturée en fin de mission.
Nos tarifs sont publics
Nous publions nos fourchettes en euros HT et notre mode de calcul en jours-homme. Voir comment se calcule le prix d’un test d’intrusion.
Vous savez qui teste
Vous connaissez le nom du consultant affecté à votre mission, ses certifications (OSCP, OSWE) et vous lui parlez directement, sans intermédiaire commercial.
Au contact de vos développeurs
Les constats critiques remontent au fil de l’eau : la correction peut commencer pendant la campagne, sans attendre la remise du rapport.
Témoignages clients
Ce que nos clients disent de nous
Foire aux questions
01 Qu’est-ce qu’OWASP ASVS exactement ?
L’Application Security Verification Standard est un référentiel ouvert, maintenu par la communauté OWASP, qui énumère plusieurs centaines d’exigences de sécurité concrètes et testables pour les applications web et mobiles. Nous l’employons comme méthodologie de vérification : il détermine ce que nous contrôlons et l’unité dans laquelle nous rendons le résultat.
Ce n’est pas un schéma de certification. Il n’existe pas de certificat ASVS et aucun prestataire ne peut vous en délivrer un. Ce que vous obtenez est un rapport indiquant, exigence par exigence, si votre application satisfait le niveau visé. Voir aussi les méthodologies OWASP.
02 Quel niveau ASVS choisir : 1, 2 ou 3 ?
Le niveau 1 convient à une application qui ne traite ni données sensibles ni transaction financière : site vitrine, blog, page de campagne. Le niveau 2 est le choix de la grande majorité des applications d’entreprise, dès lors qu’il existe un compte utilisateur, des données à caractère personnel ou de l’argent. Le niveau 3 se réserve aux systèmes dont la compromission entraîne des conséquences graves et difficilement réversibles : santé, paiement, téléservices publics, activités essentielles.
En pratique, si vous hésitez entre le 2 et le 3, préférez un niveau 2 couvert intégralement à un niveau 3 couvert à moitié. Un référentiel traité partiellement ne démontre rien, ni devant un client, ni devant un auditeur.
03 Combien coûte une vérification ASVS ?
Le prix se calcule en jours-homme multipliés par un taux journalier. Le nombre de jours dépend du niveau visé, du nombre de rôles applicatifs et du volume de fonctions à couvrir — pas du chiffre d’affaires de votre entreprise. Une application métier de taille moyenne en niveau 2 se situe le plus souvent entre 8 et 15 jours-homme.
Nous publions nos fourchettes en euros HT et notre mode de calcul, ce que peu de prestataires font en France. Le détail figure dans notre article sur le prix d’un test d’intrusion. Le devis, lui, est établi après cadrage et engage un prix ferme : pas de régularisation à la fin.
04 Combien de jours-homme faut-il prévoir ?
À titre indicatif : 5 à 8 jours-homme pour un niveau 1, 8 à 15 pour un niveau 2, 15 à 25 et au-delà pour un niveau 3 sur une application complexe. Ajoutez une demi-journée de restitution, ainsi que le contre-audit, que nous ne facturons pas.
Ces ordres de grandeur valent pour une application. Un périmètre de plusieurs applications se découpe en lots successifs : étaler un budget unique sur une surface trop large produit un rapport rassurant et faux.
05 Boîte noire ou boîte grise ?
Boîte grise, dans presque tous les cas, pour une vérification ASVS. Le contrôle d’accès représente une part importante des exigences des niveaux 2 et 3, et il ne se vérifie qu’avec des comptes de rôles différents : sans eux, personne ne peut démontrer qu’un utilisateur n’accède pas aux données d’un autre.
La boîte noire garde son intérêt pour mesurer ce qu’un attaquant découvre depuis l’extérieur, en particulier sur un périmètre largement exposé. Les deux se combinent bien : quelques jours de reconnaissance externe, puis l’essentiel de la charge en accès authentifié.
06 Le contre-audit est-il inclus ?
Oui, et sans surcoût. Après la mise en œuvre de vos correctifs, nous reprenons chacun des constats du rapport dans les 90 jours suivant sa remise, puis nous vous remettons un rapport de contre-audit distinct.
C’est ce second document que vos clients ou votre auditeur demanderont en priorité : il montre non seulement ce qui a été trouvé, mais ce qui a été refermé et à quelle date.
07 Faut-il un prestataire qualifié pour réaliser une vérification ASVS ?
Non. La qualification d’État 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 un test d’intrusion commandé par une entreprise privée. Haxoris ne détient pas cette qualification et ne le laisse pas entendre.
Un cas particulier existe : 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.
Dernière vérification : 11 septembre 2026.
08 Quelle version du référentiel : ASVS 4 ou ASVS 5 ?
La version en vigueur et recommandée est OWASP ASVS 5.0. Par rapport à l’ASVS 4, les exigences ont été réorganisées et actualisées sur ce qui se construit aujourd’hui : API, conteneurs, environnements cloud, chaîne d’approvisionnement logicielle.
Nous testons contre la dernière version en vigueur, sauf si votre client ou votre auditeur en impose explicitement une autre : nous la retenons alors et l’indiquons en tête du rapport.
09 Quelle différence entre l’ASVS et l’OWASP Top 10 ?
L’OWASP Top 10 est un document de sensibilisation : dix catégories de risques, utiles pour cadrer une discussion, insuffisantes pour conduire un test. L’ASVS est un référentiel de vérification : plusieurs centaines d’exigences testables, hiérarchisées en trois niveaux. L’ASVS couvre l’intégralité des risques du Top 10 et va nettement au-delà.
L’exécution des tests, elle, suit le Web Security Testing Guide (WSTG) pour le web et le MASTG pour les applications mobiles.
10 Devrons-nous fournir le code source ?
Uniquement pour une vérification de niveau 3, où certaines exigences ne peuvent être attestées que par lecture du code. Pour les niveaux 1 et 2, des comptes applicatifs par rôle et une présentation fonctionnelle suffisent.
Le code que vous nous confiez est traité comme une donnée confidentielle : accès restreint aux seuls consultants affectés, conservation dans l’Union européenne, suppression à l’échéance contractuelle, convention de confidentialité signée au préalable.
11 L’ASVS est-il utile pour une certification ISO 27001 ?
Oui, sur la partie technique. La mesure 8.29 de l’Annexe A d’ISO/IEC 27001 demande que la sécurité soit testée pendant le cycle de développement, et la mesure 8.8 porte sur la gestion des vulnérabilités techniques. Une vérification ASVS produit exactement le type de preuve attendu par l’auditeur : un référentiel documenté, un périmètre défini, des constats datés et un contre-audit qui démontre le traitement effectif.
Voir nos prestations liées à ISO 27001, ou l’ensemble de notre offre de test d’intrusion.
