Aller au contenu principal

Les vulnérabilités qu'on rencontre vraiment

Résumé : la sécurité applicative n'est pas un domaine infini — une dizaine de familles de vulnérabilités représentent l'essentiel de ce qu'on rencontre en pratique. Cette leçon parcourt l'OWASP Top 10 avec des exemples clairs, explique comment lire une CVE et un score CVSS, et surtout comment distinguer une vulnérabilité théorique d'une vulnérabilité réellement exploitable chez vous.

1. L'OWASP Top 10 — vue d'ensemble​

L'OWASP est une organisation à but non lucratif qui publie, tous les quatre ans environ, le classement des dix familles de risques les plus critiques pour les applications web.

Deux observations importantes sur ce classement.

D'abord, le contrôle d'accès défaillant est en première place, et ce n'est pas un hasard : c'est la vulnérabilité la plus difficile à détecter automatiquement, car aucun outil ne sait quelles données devraient être accessibles à quel utilisateur. C'est une logique métier, et seule une relecture humaine ou des tests dédiés la couvrent.

Ensuite, la mauvaise configuration (famille 5) est probablement la cause la plus fréquente d'incident réel, tout en étant la plus simple à éviter. Un stockage cloud laissé public, un compte administrateur par défaut conservé, une interface d'administration exposée : ce sont des erreurs de configuration, pas de code.

2. Les trois vulnérabilités à comprendre en détail​

L'injection SQL​

Voici la différence en code, sur un exemple volontairement simple.

# VULNÉRABLE : la saisie est collée dans le texte de la requête
requete = "SELECT * FROM produits WHERE nom = '" + saisie + "'"
curseur.execute(requete)

# SÛR : la structure et les valeurs voyagent séparément
curseur.execute("SELECT * FROM produits WHERE nom = %s", (saisie,))

Ce qu'il faut retenir de cette comparaison : la protection ne consiste pas à filtrer les caractères dangereux — cette approche est fragile et a été contournée mille fois. Elle consiste à séparer structurellement le code des données. Avec une requête paramétrée, il devient impossible que la saisie soit interprétée comme du code, quel que soit son contenu.

Le contrôle d'accès défaillant​

La distinction à ne jamais oublier : l'authentification répond à « qui êtes-vous ? », l'autorisation répond à « avez-vous le droit d'accéder à ceci ? ». Confondre les deux est l'erreur la plus répandue du développement web.

Un point important : remplacer les identifiants séquentiels par des identifiants aléatoires (UUID) rend l'exploitation plus difficile mais ne corrige rien. C'est de la sécurité par l'obscurité. La correction est la vérification d'autorisation.

Le cross-site scripting​

Bonne nouvelle sur ce point : les cadriciels modernes (React, Vue, Angular, Django, Rails) échappent les données par défaut. Le XSS est devenu bien plus rare qu'en 2010. Il réapparaît essentiellement quand on désactive volontairement cette protection — par exemple avec dangerouslySetInnerHTML en React, dont le nom constitue un avertissement explicite.

3. Lire une CVE​

4. Comprendre le score CVSS​

C'est l'erreur la plus fréquente des équipes qui découvrent la sécurité : traiter les vulnérabilités par ordre de score CVSS décroissant. Cela conduit à passer des journées sur des failles inexploitables dans votre contexte, tout en laissant de côté des problèmes réellement atteignables.

5. Ce qui compte vraiment : l'exploitabilité​

Les deux ressources à retenir de cette leçon :

La liste CISA KEV (Known Exploited Vulnerabilities) recense les vulnérabilités activement exploitées dans le monde réel. Si une faille y figure, elle est prioritaire quel que soit son score CVSS — parce que quelqu'un l'exploite en ce moment.

Le score EPSS (Exploit Prediction Scoring System) estime la probabilité qu'une vulnérabilité soit exploitée dans les trente jours. Combiné au CVSS, il permet une priorisation bien plus juste : une faille notée 9,8 avec un EPSS de 0,1 % est moins urgente qu'une faille notée 7,0 avec un EPSS de 40 %.

6. Le problème des faux positifs​

Un rapport de 3 400 alertes équivaut à aucun rapport — c'est exactement le même mécanisme que la fatigue d'alerte en observabilité. Vingt alertes traitées valent infiniment mieux que trois mille ignorées.

Retenir en 30 secondes​

  • L'OWASP Top 10 couvre l'essentiel de ce qu'on rencontre. Le contrôle d'accès défaillant est en première place.
  • Le contrôle d'accès est difficile à détecter automatiquement : aucun outil ne connaît votre logique métier.
  • La mauvaise configuration est probablement la cause la plus fréquente d'incident réel, et la plus simple à éviter.
  • Injection SQL : la solution est la requête paramétrée, qui sépare structurellement code et données. Filtrer les caractères ne suffit pas.
  • Authentification ≠ autorisation. Être connecté n'est pas avoir le droit d'accéder à cette ressource.
  • Remplacer un identifiant séquentiel par un UUID ne corrige rien — c'est de la sécurité par l'obscurité.
  • XSS : les cadriciels modernes échappent par défaut. Le risque revient quand on désactive la protection.
  • Une CVE est un identifiant public unique. Le CVSS mesure la gravité théorique, de 0 à 10.
  • Ne priorisez pas par CVSS décroissant. Ce qui compte : exposition, atteignabilité, exploit connu, sensibilité des données.
  • CISA KEV = failles activement exploitées, priorité absolue. EPSS = probabilité d'exploitation à 30 jours.
  • 3 400 alertes équivalent à zéro alerte. Bloquez sur critique et exploitable, suivez le reste.

Suivant : La chaîne d'approvisionnement logicielle : dépendances et SBOM →