L'OWASP (Open Worldwide Application Security Project) publie régulièrement un classement des dix familles de risques applicatifs Web les plus fréquentes et les plus impactantes : l'OWASP Top 10. Ce classement est devenu la référence la plus utilisée pour sensibiliser développeurs et équipes sécurité, non pas parce qu'il serait exhaustif — il ne couvre volontairement qu'une sélection de catégories — mais parce qu'il constitue un point de départ solide et largement partagé pour prioriser les efforts de sécurisation d'une application Web.

Plutôt que de chercher à mémoriser dix catégories abstraites, il est plus utile de comprendre le raisonnement derrière chacune d'entre elles : quel type d'erreur de conception ou d'implémentation elle décrit, et pourquoi cette erreur revient si souvent. Voici les familles de risques les plus significatives, avec une explication accessible même sans bagage technique approfondi.

Broken Access Control : le contrôle d'accès défaillant

Cette catégorie figure en tête du classement, et pour une bonne raison : elle regroupe tous les cas où un utilisateur parvient à accéder à des ressources ou à effectuer des actions qui ne devraient pas lui être accessibles. L'exemple le plus courant est simple à comprendre : un utilisateur consulte sa propre facture à l'adresse /factures/1042, puis modifie simplement le nombre dans l'URL pour tenter /factures/1043 — et découvre qu'il peut consulter la facture d'un autre client, parce que l'application n'a jamais vérifié que la ressource demandée appartenait bien à l'utilisateur connecté. Ce type de défaut, souvent appelé IDOR (Insecure Direct Object Reference), est l'une des vulnérabilités les plus fréquemment rencontrées en test d'intrusion, précisément parce qu'elle est simple à introduire par erreur et simple à exploiter.

Cryptographic Failures : la protection des données sensibles

Cette catégorie couvre les cas où des données sensibles — mots de passe, informations financières, données de santé — sont mal protégées : transmises sans chiffrement, stockées en clair dans une base de données, ou protégées par des algorithmes de chiffrement obsolètes. L'exemple le plus parlant reste le stockage des mots de passe : un mot de passe stocké en clair, ou avec une fonction de hachage inadaptée, transforme n'importe quelle fuite de base de données mineure en incident majeur, puisque les identifiants de tous les utilisateurs deviennent immédiatement exploitables.

Injection : mélanger code et données

Les failles d'injection (SQL, commande système, LDAP...) surviennent lorsque des données saisies par un utilisateur sont envoyées à un interpréteur — une base de données, par exemple — sans validation ni séparation stricte entre ce qui est du code et ce qui est de la donnée. Une injection SQL réussie peut permettre à un attaquant de lire, modifier ou supprimer l'intégralité d'une base de données, simplement en insérant des caractères spéciaux dans un champ de formulaire censé ne contenir qu'un nom d'utilisateur. Les requêtes préparées (qui séparent structurellement le code de la donnée) et la validation systématique des entrées restent les défenses les plus efficaces contre cette famille de vulnérabilités, connue depuis plus de vingt ans mais toujours activement exploitée.

Identification and Authentication Failures

Cette catégorie regroupe les défauts touchant à l'authentification elle-même : absence de limitation du nombre de tentatives de connexion (ce qui permet une attaque par force brute), sessions qui n'expirent jamais, ou absence d'authentification à plusieurs facteurs sur des comptes à privilèges élevés. Ces défauts sont particulièrement critiques car ils touchent directement la porte d'entrée de l'application : une fois cette porte franchie, la plupart des autres protections deviennent secondaires.

Security Misconfiguration

Une configuration par défaut laissée telle quelle en production, des messages d'erreur trop verbeux qui révèlent des détails techniques internes, des en-têtes de sécurité HTTP absents, des interfaces d'administration accessibles sans restriction : ces défauts de configuration comptent parmi les plus fréquents rencontrés en audit, et paradoxalement parmi les plus simples à corriger une fois identifiés. C'est souvent le premier point à vérifier lors d'un audit, car le rapport effort de correction / réduction de risque y est particulièrement favorable.

Vulnerable and Outdated Components

Une application moderne repose presque toujours sur un grand nombre de bibliothèques et de frameworks tiers. Lorsqu'une vulnérabilité est découverte dans l'un de ces composants et rendue publique, toutes les applications qui l'utilisent sans avoir appliqué le correctif deviennent des cibles potentielles, sans même que l'attaquant ait besoin de connaître le code source de l'application elle-même. Maintenir un inventaire à jour des dépendances utilisées et surveiller les vulnérabilités qui les concernent est devenu un contrôle de sécurité à part entière.

Insecure Design : quand le problème vient de la conception

Cette catégorie, plus récente dans le classement, se distingue des autres : elle ne décrit pas une erreur d'implémentation, mais une faiblesse présente dès la conception de la fonctionnalité, avant même la première ligne de code. Un exemple classique est un mécanisme de réinitialisation de mot de passe qui envoie un code à six chiffres sans limiter le nombre de tentatives : même parfaitement implémenté, ce mécanisme reste conceptuellement vulnérable à une attaque par force brute. Corriger ce type de défaut après coup est généralement bien plus coûteux que de l'éviter en amont, ce qui justifie d'intégrer une réflexion sécurité dès la phase de conception plutôt que de la reporter à une revue de code tardive.

Server-Side Request Forgery (SSRF)

Cette vulnérabilité survient lorsqu'une application, sur demande d'un utilisateur, effectue elle-même une requête réseau vers une adresse fournie par cet utilisateur — par exemple pour récupérer un aperçu d'image depuis une URL fournie dans un formulaire. Si cette adresse n'est pas correctement validée, un attaquant peut détourner cette fonctionnalité pour forcer le serveur à interroger des ressources internes normalement inaccessibles depuis l'extérieur, contournant ainsi les protections périmétriques classiques. Avec la généralisation des architectures cloud, où des métadonnées sensibles sont parfois exposées sur des adresses réseau internes prévisibles, cette catégorie de risque a pris une importance croissante ces dernières années.

« L'OWASP Top 10 n'est pas une liste à cocher une fois pour toutes : c'est un cadre de lecture à réutiliser à chaque étape du cycle de développement pour orienter les priorités de sécurisation. »

Comment utiliser cette liste concrètement

La vraie valeur de l'OWASP Top 10 ne réside pas dans sa mémorisation, mais dans son usage comme grille de lecture systématique : lors d'une revue de code, en se demandant pour chaque fonctionnalité manipulant des données utilisateur si l'un de ces risques pourrait s'appliquer ; lors de la conception d'une nouvelle fonctionnalité, en intégrant ces questions dès la phase de spécification plutôt qu'après la mise en production ; et bien sûr lors des tests d'intrusion, où elle sert de canevas pour structurer méthodiquement les vérifications à effectuer. Utilisée ainsi, en amont plutôt qu'en réaction à un incident, elle permet d'intégrer la sécurité comme une dimension normale du développement, plutôt que comme une contrainte découverte après coup.