Même un site web simple repose souvent sur des plateformes complexes, comme un CMS(Content management system) ou avec des API.
La sécurité ne doit plus être une arrière-pensée. C’est une exigence de base.
L’OWASP ASVS, Application Security Verification Standard, est un ensemble d’exigences pour concevoir, développer, tester et faire confirmer la sécurité des applications.
L’ASVS est un standard maintenu par la communauté OWASP. La dernière version est la 5.0.0 (mai 2025).
L’objectif de l’ASVS est de réduire la surface d’attaque, d’élever la posture de sécurité et d’augmenter la confiance des utilisateurs et partenaires.
C’est un ensemble d’outils, de cadres de travail et de référence que je vous invite fortement à découvrir et à utiliser!
Principes d’ASVS 5.0
La version 5 a été pensée autour de principes:
Application, ce qu’on sécurise, c’est l’application elle-même: son code, ses configurations et les composants qui appliquent des contrôles (ex.: authentification, autorisation).
Sécurité, chaque exigence doit réduire un vrai risque.
Vérification, tout doit être testable avec un résultat clair (réussi/échoué) et des preuves à l’appui. Les scans aident, mais on vérifie aussi la logique d’affaires et les accès.
Standard, l’ASVS dit ce qui doit être vrai, pas comment le faire. C’est un ensemble d’exigences techniques, agnostiques aux outils et technologie.
Ensuite, un item qui prend de plus en plus d’importance, c’est la “documentation des décisions de sécurité” pour faire le suivi des choix de conceptions et faciliter leurs vérifications.
Finalement, la version 5 a fait une révision des 3 niveaux pour les rendre plus faciles à utiliser.
Pourquoi OWASP ASVS
OWASP ASVS donne un langage commun et une liste claire pour sécuriser les applications. Pour une PME, c’est un moyen simple d’éviter les angles morts, d’aligner l’équipe et de prouver que la sécurité est prise au sérieux.
Standardiser ce qui compte.
ASVS propose un ensemble cohérent d’exigences applicables à tous tes projets.
Couvrir l’ensemble des contrôles.
De l’authentification à la gestion des sessions, de la validation des données à la cryptographie, ASVS incluent tout. En le suivant, on réduit les risques classiques (injection SQL, XSS contrôle d’accès défaillant) qui causent la majorité des incidents.
Faciliter les tests de sécurité.
ASVS fournit des critères de vérification concrets pour les tests manuels et automatisés. Ces critères peuvent être intégrés aux processus d’assurance qualité ou dans l’intégration continue.
Hausser la maturité des développeurs.
Les directives rendent la sécurité plus tangible pour l’équipe. On comprend pourquoi un contrôle est exigé et comment l’implanter correctement.
Améliorer la posture de sécurité.
Avec le standard ASVS, les écarts sont identifiés plus rapidement et traités avant qu’ils deviennent des vulnérabilités critiques.
Soutenir la conformité réglementaire.
ASVS aide à démontrer que des contrôles adaptés sont en place, ce qui facilite la conformité. Montrer aux clients et aux auditeurs que la sécurité applicative est gérée de façon structurée.
Réduire les coûts.
Corriger pendant le développement coûte beaucoup moins cher qu’en urgence après un incident. En prévenant les brèches, on évite aussi les amendes, frais légaux et pertes d’affaires.
Gagner la confiance des utilisateurs.
Des applications plus sûres, c’est moins de failles de sécurité. Dans un marché compétitif, cette confiance devient un avantage clair.
Comment fonctionnent les niveaux : L1, L2, L3
L’ASVS propose trois niveaux de priorité croissante pour les 345 items.
- L1 (Niveau 1) : 70 contrôles (sécurité de base, couvrant les risques connus et facilement testable, destinée aux applications à faible risque).
- L2 (Niveau 2) : 183 contrôles (protection avancée dédiée aux applications manipulant des données sensibles).
- L3 (Niveau 3) : 92 contrôles (sécurité maximale requise pour les applications critiques, comme celles de santé ou financières).
L’ASVS n’impose pas un niveau particulier. C’est votre analyse de risque, la sensibilité de l’application et les attentes de vos utilisateurs qui doivent guider le choix.
Les « décisions de sécurité documentées », c’est quoi ?
Les « décisions de sécurité documentées », c’est tout ce que l’organisation choisie en termes de sécurité et fonctions doit être écrit.
L’ASVS 5.0 demande que les choix soient rédigés, partagés et traçables.
Lors de l’audit, on vérifie que ces décisions existent et sont réalisables, puis que le code, les configurations et les processus appliquent exactement ce qui a été décidé.
Exemple: Le champ prénom doit être de moins de 50 lettres. Lorsqu’on valide en intégration, les chiffres doivent être refusés et plus de 50 lettres également.
Ce que contient l’ASVS
Le standard, c’est 345 exigences réparties dans 17 chapitres, chacun découpé en sections thématiques:
Cette structure permet de choisir ce qui est pertinent selon le contexte ; par exemple, une API machine à-machine ignorera les exigences de “V3-frontend web”.
L’ASVS emploie volontairement le mot « exigence » : il énonce ce qui doit être vrai (« must »), pas des « should » facultatifs. L’idée est de viser des objectifs de sécurité clairs, simples à comprendre et non liés à une technologie précise et cela rend indépendant le mode de vérification.
Je vous invite à cliquer sur “Follow” pour continuer d’en apprendre plus sur les sujets liés à la sécurité de l’information et à la vie privée.
