Comment lire un rapport OWASP Top 10

Un rapport de scan qui affiche cinquante alertes critiques ne décrit pas forcément cinquante compromissions possibles. Il décrit d’abord ce qu’un outil a observé, déduit ou supposé, puis le rapproche d’une taxonomie. La décision de sécurité commence après le scan, pas dans la couleur rouge du tableau de bord.

→ Lire l’explication complète de la marmotte

OWASP Top 10 : une taxonomie, pas un verdict

OWASP (Open Worldwide Application Security Project) publie le Top 10 pour classer les grandes familles de risques applicatifs. Un scanner peut rattacher une alerte à une catégorie comme le contrôle d’accès défaillant, les erreurs cryptographiques ou l’injection. Ce rattachement facilite le tri et le reporting, mais ne démontre ni l’exploitabilité ni l’impact métier.

Un scan dynamique teste une application en fonctionnement depuis son interface réseau. Un scan statique examine le code, les dépendances ou les fichiers de configuration sans exécuter l’application. Les deux approches voient des choses différentes. Un scan dynamique détectera volontiers un en-tête HTTP (Hypertext Transfer Protocol) absent ; il ne comprendra généralement pas qu’un utilisateur peut lire les factures d’un autre locataire si aucun scénario métier ne le conduit à cette route.

Le compromis central est brutal : augmenter la couverture de détection produit plus de signal, mais aussi plus de faux positifs et de dette de triage. La recommandation est de conserver une détection large en intégration continue, puis de bloquer uniquement sur des règles prouvées, exposées et remédiables. Bloquer chaque alerte de sévérité élevée transforme la sécurité en générateur de dérogations. Les dérogations finissent toujours par se reproduire seules, probablement par division cellulaire.

Une alerte OWASP Top 10 mérite donc trois questions, dans cet ordre :

Quelle preuve factuelle produit l’outil : requête, réponse, fichier, ligne de code ou dépendance ?
Quel prérequis doit posséder l’attaquant : accès Internet, compte authentifié, rôle précis, position réseau ou interaction d’une victime ?
Quelle propriété est atteinte : confidentialité, intégrité, disponibilité, ou contrôle d’accès à une fonction métier ?

Sans réponse à la première question, l’alerte est une hypothèse. Sans réponse aux deux suivantes, la sévérité reste une estimation de catalogue.

Triage des alertes : preuve, exposition et chemin d’attaque

Commencer par dédupliquer. Dix occurrences de la même bibliothèque vulnérable dans dix images de conteneur ne représentent pas dix chemins d’attaque si toutes proviennent de la même image de base. À l’inverse, une même faiblesse sur une interface d’administration publique et sur un outil interne isolé ne porte pas le même risque.

Pour chaque finding, conserver une fiche de triage avec l’identifiant de règle, la catégorie OWASP, l’actif affecté, la version observée, la preuve, l’exposition réseau, le niveau d’authentification requis et la décision. Une référence CVE (Common Vulnerabilities and Exposures) identifie une vulnérabilité publiée. Une note CVSS (Common Vulnerability Scoring System) estime une gravité technique générique. Ni la CVE ni le CVSS ne connaissent les flux métier, les contrôles compensatoires ou la segmentation locale.

La priorité réelle suit plutôt cette formule :

priorité = preuve reproductible × exposition × exploitabilité × impact métier

Une injection SQL (Structured Query Language) confirmée sur une route publique justifie une correction immédiate, même si l’outil hésite entre plusieurs catégories OWASP. Un cookie sans attribut SameSite sur une interface sans session sensible peut être documenté et planifié. Ce n’est pas une invitation à oublier le sujet : c’est une manière d’éviter que la correction urgente se noie dans le papier peint de conformité.

Pour les alertes de contrôle d’accès, tester au moins deux identités distinctes et une requête directe vers la ressource cible. Une réponse 200 OK à une URL devinée ne prouve rien si elle retourne une page vide ou les données du demandeur. La preuve attendue est la lecture ou la modification d’un objet appartenant à une autre identité, avec les traces minimales permettant de reproduire le test.

Les alertes d’injection exigent aussi une preuve. Les trier suppose de savoir qui exécute quoi entre JavaScript et SQL : un scanner ne fait pas la différence, c’est même à cela qu’on le reconnaît. Une entrée reflétée dans une réponse n’est pas forcément une injection exécutable. Pour une injection de script côté navigateur, vérifier le contexte de sortie : texte HTML (Hypertext Markup Language), attribut, URL (Uniform Resource Locator), JavaScript ou feuille de style. La contre-mesure dépend du contexte, donc une fonction d’échappement universelle est un mensonge confortable.

Prérequis de plateforme pour un scan exploitable

Un scan répétable dépend d’un environnement stable. Définir les URL autorisées, les comptes de test, les rôles, les données non sensibles, les plages d’adresses et la fenêtre d’exécution avant de lancer l’outil. Scanner une production sans périmètre ni limitation de débit reste une façon sophistiquée d’organiser un incident de disponibilité.

Les comptes de scan doivent être dédiés, nommés et limités au jeu de droits nécessaire. Une authentification par mot de passe impose un secret stocké dans un gestionnaire de secrets ; une authentification par jeton impose une durée de vie courte et une révocation testée. Ne jamais placer un jeton dans une variable de pipeline visible dans les journaux, les artefacts ou les diagnostics d’échec. Un jeton de scan ayant le droit de modifier des données de production n’est pas un prérequis, c’est une anomalie avec un badge.

Versionner les règles, le moteur de scan et le fichier de configuration. Un résultat n’est comparable dans le temps que si la version de l’outil, les signatures de détection et le périmètre sont connus. Archiver le rapport brut, mais chiffrer les artefacts lorsqu’ils contiennent des réponses applicatives, des identifiants de session ou des données personnelles.

La chaîne d’intégration continue doit inclure au minimum :

une analyse des dépendances et de leurs vulnérabilités connues ;
une analyse statique des règles de code à haut signal ;
un scan dynamique contre un environnement de test isolé ;
une revue manuelle des fonctions d’autorisation, des flux de paiement, des exports et des interfaces d’administration.

Les sujets de gestion des identités déterminent directement la qualité du résultat. Une couverture sans comptes de test représentatifs ignore souvent les défauts les plus graves. La page sur les identités complète ce point ; les mécanismes de base restent également décrits dans la rubrique développement.

Exemple reproductible avec OWASP ZAP

OWASP ZAP (Zed Attack Proxy) peut produire un rapport de référence à partir d’une cible publique de démonstration. Le scan de base réalise principalement des contrôles passifs et des requêtes limitées. Il ne remplace pas un test d’intrusion ni une revue de logique métier.

# Exécuter OWASP ZAP 2.16.1 dans un conteneur éphémère.
# La cible example.org est volontairement publique et non sensible.
docker run --rm -t \
  -v "$PWD/zap-reports:/zap/wrk:rw" \
  zaproxy/zap-stable:2.16.1 \
  zap-baseline.py \
  -t https://example.org \
  -r rapport-zap.html \
  -J rapport-zap.json

# Extraire les alertes qui exigent une revue humaine.
jq -r '
  .site[].alerts[]
  | select(.riskcode | tonumber >= 2)
  | [.alert, .riskdesc, .confidence, .url]
  | @tsv
' zap-reports/rapport-zap.json

Le fichier JSON (JavaScript Object Notation) doit être la source de triage, pas seulement le rapport HTML destiné à la lecture. Conserver la requête et la réponse associées à chaque alerte retenue. Si l’outil signale l’absence de l’en-tête Content-Security-Policy, vérifier d’abord si l’application délivre du contenu HTML actif. Une API (Application Programming Interface) JSON sans navigateur n’expose pas le même vecteur qu’un portail utilisateur.

Épingler l’image par digest cryptographique dans une chaîne de production évite qu’un tag identique change silencieusement. Le tag est pratique ; le digest est vérifiable. Les slides de vendeurs confondent régulièrement les deux, sans doute parce qu’un condensat SHA-256 tient moins bien dans une bulle pastel.

Surface d’attaque et contre-mesures par catégorie

Les catégories OWASP doivent conduire vers des contre-mesures précises, pas vers une séance de coloriage de cellules rouges.

Le contrôle d’accès défaillant se traite côté serveur, sur chaque opération et chaque objet. Cacher un bouton dans l’interface ne retire aucun droit. Utiliser une décision d’autorisation centralisée, vérifier la relation entre l’identité et la ressource, puis couvrir les identifiants directs, les exports, les recherches et les opérations par lot.

Les défauts cryptographiques couvrent le transport, le stockage et la gestion des secrets. Imposer TLS (Transport Layer Security) avec validation stricte du certificat, chiffrer les données réellement sensibles et séparer les clés des données. Le chiffrement ne corrige pas une autorisation absente : un attaquant autorisé par erreur recevra des données parfaitement chiffrées, puis parfaitement déchiffrées par le service.

Les injections se réduisent par requêtes paramétrées, validation syntaxique stricte et séparation des interpréteurs. Interdire les constructions de requête dynamiques, y compris lorsqu’elles sont bâties par un générateur d’intelligence artificielle. Une chaîne générée automatiquement reste une chaîne, pas une déclaration de non-responsabilité.

Les requêtes côté serveur falsifiées, souvent nommées SSRF (Server-Side Request Forgery), exigent une sortie réseau contrôlée. Restreindre les destinations par liste d’autorisation, résoudre et vérifier les adresses après résolution DNS (Domain Name System), bloquer les plages internes et empêcher les redirections non attendues. Filtrer une URL textuelle sans contrôler la destination réellement atteinte laisse la porte ouverte aux contournements par redirection ou résolution rebond.

Les composants vulnérables réclament un inventaire logiciel, une politique de mise à jour et une suppression des dépendances inutilisées. Une dépendance non appelée mais embarquée dans l’image reste parfois exploitable via une fonction exposée par défaut. L’image de conteneur n’est pas un sac magique où les bibliothèques deviennent inoffensives en silence.

Exploitation, rotation et limites du rapport

Un rapport de scan ne garantit pas l’absence de vulnérabilité. Il ne prouve pas la sécurité des contrôles métier, ne détecte pas toutes les chaînes d’attaque et ne remplace pas la surveillance. Les attaques par bourrage d’identifiants, abus de privilèges, fraude logique et exfiltration lente échappent souvent à une détection purement applicative.

Superviser les exécutions de scan, leurs échecs d’authentification, les changements de périmètre et les tendances d’alertes confirmées. Une chute brutale du nombre de résultats peut signaler une amélioration, mais aussi un compte expiré, une route devenue inaccessible ou une règle désactivée. Les métriques sans contrôle de santé sont des thermomètres placés dans le congélateur.

Prévoir la rotation des secrets de scan, des certificats clients et des comptes de test. Tester la reprise après perte d’un rapport ou d’un environnement de test : restaurer la configuration versionnée, recréer les comptes, réinjecter des données synthétiques et relancer le scan doit rester possible sans récupérer un ancien secret. Les sauvegardes des rapports doivent suivre la même politique de rétention que les journaux de sécurité, car elles peuvent contenir des preuves exploitables.

Les vulnérabilités validées alimentent enfin la gestion des failles avec un propriétaire, une échéance, une correction vérifiée et une exception limitée dans le temps. La rubrique failles fournit le cadre voisin : le scan détecte, le processus de remédiation réduit le risque. Confondre les deux revient à confondre une alarme incendie avec un extincteur.

🐝 Ce qui arrive si on s’en passe

Sans lecture structurée du rapport, le fichier de scan devient un stock d’alertes non qualifiées : personne ne sait lesquelles ont été vues, écartées ou corrigées, et la même faiblesse réapparaît à la livraison suivante sans que rien ne la distingue du bruit déjà présent. Les preuves (requête, réponse, identifiant de règle) ne sont pas conservées, donc une correction ne peut plus être vérifiée ni une régression démontrée. Les artefacts bruts, laissés en clair dans les espaces de build, transportent des jetons de session et des extraits de réponses applicatives réutilisables par quiconque accède au dépôt. Sans versionnement du moteur et du périmètre, deux exécutions ne sont plus comparables : une baisse d’alertes causée par un compte expiré ou une route injoignable se lit comme un progrès, et la porte reste ouverte sans que le compteur bouge.

🦫 Explication de la marmotte 🍫

Un rapport de scan est produit par un programme qui envoie des demandes à une application, lit les réponses et cherche des signes de faiblesse. Il peut aussi examiner le code ou la liste des logiciels inclus dans l’application. Il range ensuite ses résultats dans de grandes familles d’erreurs fréquentes : accès accordé à la mauvaise personne, données mal protégées, commande mal interprétée ou logiciel connu pour contenir un défaut.

Chaque résultat doit être vérifié. Il faut conserver la demande envoyée, la réponse reçue et les conditions nécessaires pour reproduire le problème. Une alerte devient prioritaire si elle fonctionne réellement, si l’application est accessible, si peu de droits sont nécessaires et si elle permet de lire, modifier ou bloquer des données sensibles.

Le scan doit utiliser des comptes réservés aux tests, avec des droits limités et des secrets gardés hors des journaux. Son programme, ses règles et son périmètre doivent être enregistrés pour comparer les résultats dans le temps. Les rapports peuvent contenir des informations sensibles, donc ils doivent être protégés et supprimés selon une durée prévue.

Quand une faiblesse est confirmée, il faut corriger la cause, tester la correction, puis garder une trace de la décision. Si le scan échoue, si son compte expire ou si une partie de l’application devient inaccessible, moins d’alertes ne signifie pas que le système est devenu plus sûr.