OWASP ASVS (Application Security Verification Standard) est le standard de référence en 2026 pour spécifier les exigences de sécurité applicative. La version 5.0 (publiée 2024) en a fait un référentiel pratique, modulaire, mappable sur les autres standards (CWE, NIST, ISO 27001). Le niveau 2 est devenu le baseline attendu pour la majorité des SaaS B2B européens. Voici ce qu'il implique concrètement.
Les 3 niveaux ASVS
Niveau 1 — Opportunistic
Couvre les attaques opportunistes basiques. Adapté aux applications avec peu de données sensibles. C'est ce que vous obtiendriez en suivant les bonnes pratiques de base.
Niveau 2 — Standard
Adapté à la majorité des applications B2B traitant des données sensibles (mais pas vitales). C'est le niveau cible pour un SaaS B2B sérieux en 2026.
Niveau 3 — Advanced
Pour les applications critiques (finance, santé, infrastructure). Nécessite des vérifications par des experts dédiés.
Les 14 chapitres de ASVS 5.0
L'ASVS organise les contrôles en chapitres :
- V1 Architecture, Design and Threat Modeling
- V2 Authentication
- V3 Session Management
- V4 Access Control
- V5 Validation, Sanitization, Encoding
- V6 Cryptography
- V7 Error Handling and Logging
- V8 Data Protection
- V9 Communications
- V10 Malicious Code
- V11 Business Logic
- V12 Files and Resources
- V13 API and Web Service
- V14 Configuration
Pour le niveau 2, environ 200 contrôles à valider.
Les implications opérationnelles
V1 — Threat modeling
L1 demande qu'un threat model existe. L2 demande qu'il soit maintenu et qu'il guide les choix d'architecture.
Implication : threat modeling devient une discipline opérationnelle, pas un exercice unique. Refresh à chaque feature majeure.
V2 — Authentication
L1 : password length, MFA optionnel. L2 : MFA obligatoire pour les utilisateurs avec accès sensible. Mots de passe vérifiés contre listes de breach (Have I Been Pwned).
Implication : intégration HIBP API ou équivalent dans votre pipeline d'inscription.
V3 — Session management
L1 : sessions sécurisées de base. L2 : timeouts adaptés au risque, rotation de session après authentification, invalidation côté serveur explicite, protection contre fixation de session.
V4 — Access control
L1 : contrôles d'accès basiques. L2 : principle of least privilege appliqué partout. Tests d'autorisation systématiques (verticaux et horizontaux). Logging des décisions d'autorisation.
C'est typiquement la zone où les SaaS B2B ont le plus de gap. Beaucoup ont un RBAC primitif ("admin/user") qui ne survit pas à un audit L2.
V5 — Validation et encoding
L1 : validation des inputs basiques. L2 : validation systématique côté serveur, encoding contextuel, protection contre injection (SQL, command, LDAP, XPath, etc.), validation des uploads de fichiers.
Implication : un framework de validation cohérent (zod, Joi, Pydantic) appliqué partout, pas par endroits.
V6 — Cryptography
L1 : pas de cryptographie cassée. L2 : algorithmes modernes (AES-256, RSA-3072, ChaCha20Poly1305), gestion correcte des clés (KMS), pas de roll-your-own crypto.
V7 — Error handling et logging
L1 : pas de fuite via erreurs. L2 : logging structuré, événements de sécurité tracés, conservation appropriée, protection contre injection dans les logs.
Implication : une stack de logging mature (structured logs, central SIEM/log aggregator).
V8 — Data protection
L1 : pas de données en clair en stockage. L2 : classification des données, encryption at-rest avec gestion de clé, encryption in-transit avec TLS 1.2+ (1.3 préféré), purge correcte.
V13 — API et services web
L1 : auth basique. L2 : rate limiting, validation stricte des contrats d'API (OpenAPI), authentification mutuelle pour les services internes, protection contre les attaques CORS, CSRF.
La roadmap ASVS L2 sur 6-9 mois
Mois 1 — Diagnostic
- Mapper votre application actuelle contre les 200 contrôles L2.
- Identifier les gaps majeurs.
- Prioriser par risque.
Outil : la spreadsheet ASVS officielle, ou une plateforme comme SecureFlag.
Mois 2-4 — Quick wins
Souvent, 30-40% des contrôles sont déjà satisfaits par vos pratiques actuelles, juste pas documentés. Documentation des contrôles existants.
Quick wins typiques :
- Activation rate limiting global au niveau API gateway.
- Force TLS 1.3 minimum.
- Header de sécurité (CSP, HSTS, X-Frame-Options) au niveau reverse proxy.
- Logging structuré si pas déjà en place.
Mois 4-7 — Chantiers structurels
Ceux qui demandent du dev :
- Refactoring du système d'autorisation pour passer à un vrai RBAC ou ABAC.
- Threat modeling systématique sur les features sensibles.
- Tests d'autorisation horizontaux et verticaux automatisés.
- Integration HIBP, validation forte des passwords.
Mois 7-9 — Documentation et audit
- Documentation des contrôles dans un registre auditable.
- Audit interne (ou par un cabinet externe) qui valide la posture L2.
- Plan de maintenance continue.
Coûts réalistes
Pour une scale-up de 30-100 personnes avec une application déjà en prod :
- Diagnostic : 5-15 k€ (consulting) + 1-2 semaines équipe interne.
- Mise en conformité : 6-12 mois calendaires, 1-2 ETP partiels équivalents.
- Audit externe : 10-25 k€.
Total ordre de grandeur : 100-200 k€ tout compris.
ROI : ASVS L2 est un argument commercial fort dans les DDQ B2B. Plusieurs des grandes plateformes d'achat enterprise demandent désormais une preuve d'alignement.
Articulation avec ISO 27001
ASVS et ISO 27001 sont complémentaires, pas redondants :
- ISO 27001 : système de management, gouvernance, politiques.
- ASVS : exigences techniques sur l'application elle-même.
Pour un SaaS B2B sérieux : viser les deux en parallèle. Beaucoup de mutualisation possible.
Voir ISO 27001 pour SaaS B2B : roadmap 12 mois.
La règle d'or
Comme pour les autres standards : ASVS pour de vrai, pas pour le papier. Cocher des cases sans avoir la posture sécurité produit du papier audit-friendly mais ne change rien à la sécurité réelle.
L'ASVS bien implémenté change la qualité du code et la résilience de l'application. Mal implémenté, c'est de la dette technique pour la prochaine équipe.
