OWASP Top 10 ASVS ZAP et sécurité applicative

L’Open Worldwide Application Security Project (OWASP) est une fondation à but non lucratif consacrée à la sécurité des applications. Elle ne publie ni loi, ni certification étatique, ni doctrine nationale : elle fournit des référentiels et des outils que les équipes peuvent intégrer directement dans leurs pratiques de développement, d’architecture et de test.

→ Lire l’explication complète de la marmotte

OWASP : mandat communautaire et périmètre réel

L’OWASP est porté par une communauté ouverte de bénévoles, de chapitres locaux, de mainteneurs de projets, de donateurs et de sponsors. Cette gouvernance est sa force et sa limite. Elle permet une diffusion mondiale rapide, sans dépendre d’une administration nationale ou d’un cycle réglementaire. Elle ne remplace pas, en revanche, une exigence contractuelle, une obligation légale ou une analyse de risque propre à un secteur.

Le compromis central est net : on gagne des référentiels utilisables partout et compris par presque toutes les équipes applicatives, mais on paie cette universalité par une granularité parfois insuffisante pour arbitrer un contexte métier précis. Le Top 10 OWASP ne sait pas si une faille de contrôle d’accès expose un profil public ou une fonction de paiement. Il décrit une classe de risque, pas la valeur de l’actif touché.

Cette indépendance explique son adoption. Une équipe répartie entre plusieurs pays peut définir un vocabulaire de sécurité commun sans négocier d’abord quelle doctrine nationale doit servir de base. Cela rend l’OWASP particulièrement efficace pour les produits SaaS (Software as a Service), les chaînes CI/CD (Continuous Integration and Continuous Delivery) et les fournisseurs de logiciels. Les frontières administratives ralentissent rarement une injection SQL, ce défaut a la délicatesse de voyager seul.

L’OWASP doit être placé aux côtés des référentiels institutionnels, pas à leur place. Le NIST structure des contrôles et des cadres de gestion du risque à grande échelle. L’ANSSI apporte une doctrine française et des recommandations d’architecture. L’OWASP intervient plus près du code, des interfaces de programmation et des flux HTTP (Hypertext Transfer Protocol).

Le financement mixte, composé de dons, de sponsoring et de cotisations de chapitres, évite une dépendance directe à un État ou à un fournisseur. Il impose toutefois de vérifier la maturité de chaque projet. Un document OWASP célèbre n’est pas automatiquement maintenu au même rythme qu’un standard industriel. La notoriété n’est pas un mécanisme de gestion de versions, même si certaines slides de gouvernance tentent encore de le faire croire.

Top 10 OWASP : un langage de priorisation, pas un plan de remédiation

Le Top 10 OWASP recense périodiquement les catégories de risques applicatifs les plus critiques observées dans les retours de terrain, les données de tests et les contributions de la communauté. Les éditions récentes couvrent notamment les défaillances de contrôle d’accès, les erreurs cryptographiques, les injections, la conception non sécurisée, les mauvaises configurations, les composants vulnérables et les erreurs de journalisation ou de supervision.

Son usage correct consiste à établir une couverture minimale. Chaque catégorie doit être reliée à des exigences de conception, à des contrôles automatisés, à des tests manuels et à un responsable de traitement. Affirmer qu’une application « respecte le Top 10 » sans matrice de preuves revient à certifier qu’un parapluie respecte la météo.

Le contrôle d’accès défaillant mérite une attention particulière. Vérifier qu’un bouton d’interface est masqué ne protège rien : l’autorisation doit être contrôlée côté serveur, sur chaque requête, à partir de l’identité authentifiée et de l’objet demandé. Une règle d’accès fondée sur un identifiant transmis par le client est contournable dès lors qu’un attaquant peut modifier cet identifiant. Les tests doivent donc rechercher les accès horizontaux, entre comptes de même rôle, et verticaux, vers un rôle plus privilégié.

Les erreurs cryptographiques exigent une lecture tout aussi stricte. Le chiffrement du transport avec TLS (Transport Layer Security) ne protège pas les données stockées, et le hachage rapide d’un mot de passe ne constitue pas un stockage de mot de passe acceptable. Il faut utiliser une fonction de dérivation de clé prévue pour cet usage, avec un sel unique et des paramètres de coût maintenus. Le Top 10 signale le danger ; l’architecture doit préciser les algorithmes, la rotation et les emplacements de clés.

Le Top 10 ne garantit pas l’absence de vulnérabilité. Il ne couvre pas exhaustivement les erreurs de logique métier, les fraudes, les abus de fonctions légitimes, les chaînes d’approvisionnement compromises ni la disponibilité. Une application peut cocher toutes ses catégories et permettre tout de même un remboursement frauduleux parce que le modèle métier l’autorise. Le logiciel n’a pas besoin d’une injection pour prendre une mauvaise décision.

ASVS : transformer les catégories OWASP en exigences vérifiables

L’Application Security Verification Standard (ASVS) est le référentiel à privilégier pour transformer les thèmes du Top 10 en exigences testables. Il structure la vérification autour de domaines comme l’architecture, l’authentification, la gestion de session, le contrôle d’accès, la validation des entrées, la cryptographie, les erreurs, les journaux et les interfaces de programmation.

L’ASVS propose trois niveaux de vérification. Le niveau 1 vise une confiance de base pour des applications à faible exposition. Le niveau 2 constitue le minimum raisonnable pour une application contenant des données sensibles ou des fonctions métier significatives. Le niveau 3 vise les applications à fort impact, notamment quand une compromission peut affecter durablement des infrastructures, des données très sensibles ou des transactions critiques.

La recommandation est de contractualiser au minimum l’ASVS niveau 2 pour toute application exposée à Internet ou traitant des données à caractère personnel. Le niveau 1 est trop faible comme objectif cible : il peut servir de seuil d’entrée, jamais de ligne d’arrivée. Le niveau 3 doit être choisi après analyse de risque, car il introduit des exigences de conception, d’isolation et de vérification qui ont un coût réel.

Chaque exigence retenue doit produire une preuve : revue d’architecture, résultat de test, configuration versionnée, contrôle de pipeline ou test de régression. Une exigence non reliée à une preuve finit généralement dans un tableur fossilisé, juste entre « à revoir » et « critique basse ».

L’ASVS ne garantit pas la qualité opérationnelle du système. Il ne remplace ni la gestion des secrets, ni la sauvegarde, ni la surveillance des dépendances, ni la réponse à incident. Les secrets d’application doivent venir d’un gestionnaire dédié, être séparés par environnement et ne jamais être injectés dans une image de conteneur. La rotation doit être testée en conditions normales : une rotation qui exige une interruption imprévue n’est pas une rotation, c’est une panne programmée avec une documentation optimiste.

ZAP : automatiser le contrôle HTTP sans transformer le test en permission

Zed Attack Proxy (ZAP) est un outil open source de test de sécurité applicative piloté par l’OWASP. Il agit comme proxy d’interception et peut exécuter des analyses passives ou actives sur des applications web. Son adoption vient de son intégration facile dans les environnements de développement et de CI/CD, pas d’une propriété magique de détection.

L’analyse passive observe les réponses HTTP sans envoyer de charges offensives supplémentaires. Elle détecte notamment certains en-têtes de sécurité absents, des cookies mal configurés ou des fuites d’information. L’analyse active envoie des requêtes de test susceptibles de modifier des données, de provoquer des erreurs ou de saturer une application fragile. Elle ne doit jamais viser un environnement sans autorisation explicite ni données de test isolées.

ZAP convient pour détecter une régression de configuration et alimenter un flux de triage. Il ne remplace pas une revue de code, une analyse de dépendances ni un test d’intrusion manuel. Un scanner ne comprend pas qu’une remise de 100 % appliquée dix fois est une fraude métier. Il voit des réponses HTTP ; le métier, lui, a parfois inventé ses propres vulnérabilités avec un enthousiasme remarquable.

Exemple : exécuter un contrôle passif ZAP sur une application locale

Le scénario suivant lance une application volontairement vulnérable en local puis exécute le scan de référence ZAP. L’analyse cible exclusivement localhost et produit un rapport HTML (HyperText Markup Language).

# Démarrer une cible locale isolée, exposée uniquement sur le poste de travail.
docker run --rm -d --name juice-shop -p 127.0.0.1:3000:3000 bkimminich/juice-shop

# Attendre que l'application réponde avant le contrôle passif.
until curl --fail --silent http://127.0.0.1:3000/ >/dev/null; do sleep 2; done

# Lancer ZAP en mode baseline : aucune analyse active, rapport écrit dans le répertoire courant.
docker run --rm --network host -v "$PWD:/zap/wrk:rw" \
  zaproxy/zap-stable zap-baseline.py \
  -t http://127.0.0.1:3000 \
  -r zap-baseline.html

# Arrêter la cible locale après le test.
docker stop juice-shop

En CI/CD, l’échec du pipeline ne doit pas être déclenché indistinctement sur chaque alerte. Il faut versionner une politique de sévérité, définir les exceptions avec une date d’expiration et bloquer les alertes nouvelles correspondant à des catégories exploitables. Ignorer toutes les alertes parce que quelques faux positifs existent est une tradition très répandue, presque patrimoniale, mais elle ne réduit aucune exposition.

Exploitation des référentiels OWASP et limites de sécurité

L’intégration opérationnelle suit un ordre qui évite les contrôles décoratifs. D’abord, sélectionner le niveau ASVS selon la criticité et traduire ses exigences en critères d’architecture. Ensuite, mapper les catégories du Top 10 aux menaces et aux composants exposés. Enfin, automatiser les vérifications répétables avec ZAP, analyse de dépendances et tests d’interface, puis réserver le test humain aux logiques complexes et aux chemins d’attaque crédibles.

Les prérequis de plateforme sont concrets : inventaire des applications et de leurs interfaces, environnements de test isolés, comptes de test non privilégiés, données synthétiques, journalisation corrélable et gestion centralisée des secrets. Pour les applications conteneurisées, l’image de test doit être identique au binaire distribué, avec des paramètres d’environnement spécifiques. Scanner une maquette qui ne partage ni routes, ni authentification, ni dépendances avec le produit livré produit surtout un rapport très propre.

La surface d’attaque de cette démarche inclut les comptes utilisés par les scanners, les jetons d’accès aux environnements de test, les rapports contenant des URL ou paramètres sensibles et les exceptions de sécurité. Un jeton ZAP ayant des privilèges administratifs élargit le risque au lieu de le mesurer. Utiliser des comptes dédiés, à privilèges minimaux, à durée de vie courte et révoqués après usage.

Les rapports doivent être archivés avec les artefacts de livraison et protégés comme des informations de sécurité. Les sauvegardes doivent inclure les politiques de scan, les listes d’exclusion et la matrice ASVS, sinon une restauration ne récupère qu’un outil vide. Superviser aussi l’exécution : une baisse soudaine du nombre de routes analysées peut signaler une régression d’authentification ou de découverte, pas une amélioration miraculeuse de la sécurité.

Pour situer ces pratiques dans une architecture plus large, les contrôles applicatifs doivent être reliés aux principes de gouvernance et aux mécanismes de développement sécurisé. L’OWASP fournit les critères techniques ; l’organisation doit fournir la responsabilité, la priorisation et la capacité de corriger.

🐝 Ce qui arrive si on s’en passe

Sans référentiel applicatif appliqué, les défauts ne sont plus nommés de la même façon d’une équipe à l’autre, et un correctif livré ne peut pas être rattaché à une exigence : la comparaison entre deux versions devient impossible, faute de base de référence. Sans exigences vérifiables sur les messages d’erreur et les réponses différenciées, un service continue de répondre distinctement selon la validité d’une donnée reçue, mécanisme exploité dans la brèche « la question qui rend le module bavard ». Sans contrôle automatisé récurrent, une régression de configuration (en-tête retiré, cookie sans attribut, route rouverte) passe inaperçue jusqu’au prochain audit manuel. Sans archivage des rapports et des politiques de scan, il ne reste aucune trace permettant de dater l’apparition d’une exposition ni de prouver qu’une correction a tenu.

🦫 Explication de la marmotte 🍫

Cette fondation mondiale publie des ressources pour réduire les défauts de sécurité dans les sites web et les logiciels. Elle n’est pas une administration : ses documents sont écrits et entretenus par une communauté internationale. Les équipes choisissent donc de les utiliser, souvent parce qu’ils sont connus dans de nombreux pays.

Sa liste la plus célèbre classe les grandes familles de problèmes dangereux. Elle aide à vérifier, par exemple, qu’une personne ne peut pas lire les données d’un autre compte, qu’un formulaire ne laisse pas entrer des commandes malveillantes et qu’un réglage technique ne révèle pas des informations confidentielles. Cette liste indique les risques à rechercher, mais elle ne prouve pas qu’un logiciel est sûr.

Un autre document transforme ces risques en exigences vérifiables. Une équipe sélectionne un niveau selon les conséquences possibles d’un incident, puis conserve une preuve pour chaque exigence : test, réglage ou examen du code. Les exigences doivent aussi couvrir les mots de passe, les accès, les données enregistrées et les messages d’erreur.

Un outil gratuit peut ensuite examiner automatiquement un site de test. Il envoie ou observe des requêtes et signale certains défauts. Si l’outil ne peut pas se connecter, si son compte est trop puissant ou si ses alertes sont ignorées, le résultat devient trompeur. Les équipes doivent donc protéger ses accès, conserver ses réglages, surveiller ses résultats et faire vérifier par des personnes les règles métier que l’outil ne comprend pas.

Pages voisines

La citent

OWASP Top 10 ASVS ZAP et sécurité applicative

Elle cite

OWASP Top 10 ASVS ZAP et sécurité applicative

OWASP Top 10 ASVS ZAP et sécurité applicative

OWASP : mandat communautaire et périmètre réel

Top 10 OWASP : un langage de priorisation, pas un plan de remédiation

ASVS : transformer les catégories OWASP en exigences vérifiables

ZAP : automatiser le contrôle HTTP sans transformer le test en permission

Exemple : exécuter un contrôle passif ZAP sur une application locale

Exploitation des référentiels OWASP et limites de sécurité

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines