Checklist OWASP Top 10 expliquée aux non-experts
Les dix catégories de risques applicatifs de l'OWASP traduites en langage clair, avec ce que chacune signifie concrètement pour une application SaaS et comment la vérifier.
- OWASP
- Vulnérabilités
Sommaire
- A01 : contrôle d’accès défaillant
- A02 : défaillances cryptographiques
- A03 : injection
- A04 : conception non sécurisée
- A05 : mauvaise configuration de sécurité
- A06 : composants vulnérables et obsolètes
- A07 : défaillances d’identification et d’authentification
- A08 : défaut d’intégrité des données et du logiciel
- A09 : carences de journalisation et de supervision
- A10 : falsification de requête côté serveur (SSRF)
- Comment s’en servir sans le déformer
L’OWASP Top 10 est la référence la plus citée en sécurité applicative, et l’une des plus mal comprises. Ce n’est pas une liste des dix failles les plus dangereuses, ni un standard de conformité : c’est un classement de catégories de risques, établi à partir de données collectées sur un grand nombre d’applications. Le lire comme une checklist de conformité conduit à des erreurs d’interprétation ; le lire comme une grille de lecture est bien plus utile.
Voici ces catégories en langage clair, avec, pour chacune, la question que vous pouvez poser à votre équipe technique.
A01 : contrôle d’accès défaillant
En clair : un utilisateur accède à quelque chose qui ne lui appartient pas. Le compte est authentifié, mais l’application ne vérifie pas correctement ses droits sur la ressource demandée.
C’est la catégorie la plus fréquemment rencontrée sur les applications SaaS, et la plus coûteuse : elle mène directement à des données d’un client visibles par un autre.
La question à poser : « Où le contrôle d’appartenance à l’organisation est-il appliqué ? Dans chaque contrôleur, ou dans la couche d’accès aux données ? »
A02 : défaillances cryptographiques
En clair : des données sensibles sont mal protégées, qu’elles soient transmises en clair, stockées sans chiffrement ou couvertes par des mécanismes obsolètes.
Attention au contresens fréquent : chiffrer une base de données au repos ne protège pas contre une faille applicative. Si l’application a le droit de lire les données, un attaquant qui passe par l’application aussi.
La question à poser : « Quelles données considérons-nous comme sensibles, et quel traitement spécifique reçoivent-elles à chaque étape ? »
A03 : injection
En clair : une donnée fournie par l’utilisateur est interprétée comme une instruction. Cela couvre l’injection SQL, mais aussi l’injection de commandes système, l’injection dans les moteurs de templates et le XSS (script exécuté dans le navigateur d’un autre utilisateur).
La question à poser : « Où construisons-nous encore des requêtes ou des commandes par concaténation de chaînes ? »
A04 : conception non sécurisée
En clair : le problème n’est pas dans l’implémentation mais dans la conception. Le code fait exactement ce qui était prévu ; ce qui était prévu est risqué. Exemples : un processus de récupération de compte reposant sur une question secrète, une remise commerciale calculée côté client, une absence totale de limitation sur une opération coûteuse.
La question à poser : « À quel moment de la conception d’une nouvelle fonctionnalité posons-nous la question de son détournement possible ? »
A05 : mauvaise configuration de sécurité
En clair : l’application ou son infrastructure sont mal paramétrées. Comptes par défaut conservés, messages d’erreur détaillés exposés en production, interface d’administration accessible publiquement, en-têtes de sécurité absents, permissions de stockage trop larges.
C’est la catégorie où l’écart entre les environnements se paie : une configuration durcie en production mais laxiste en recette suffit à exposer les mêmes données.
La question à poser : « Quelles différences de configuration existent entre notre recette et notre production, et sont-elles documentées ? »
A06 : composants vulnérables et obsolètes
En clair : vous utilisez des bibliothèques tierces comportant des failles connues et publiées. L’attaquant n’a rien à découvrir : la faille est documentée, souvent accompagnée d’un code de démonstration public.
La question à poser : « Qui reçoit les alertes de sécurité sur nos dépendances, et quel est notre délai cible de mise à jour pour une faille critique ? »
A07 : défaillances d’identification et d’authentification
En clair : les mécanismes de connexion peuvent être contournés ou abusés : absence de protection contre le bourrage d’identifiants, jetons de session mal gérés, second facteur contournable, réinitialisation de mot de passe défaillante.
La question à poser : « Que se passe-t-il exactement quand un utilisateur change son mot de passe ou se déconnecte ? Les sessions ouvertes ailleurs sont-elles révoquées ? »
A08 : défaut d’intégrité des données et du logiciel
En clair : vous faites confiance à quelque chose dont vous ne pouvez pas vérifier l’origine : dépendance récupérée sans vérification, mise à jour non signée, désérialisation de données provenant du client, script tiers chargé depuis un domaine externe.
La question à poser : « Quel code exécuté en production ne provient pas de notre dépôt, et comment en vérifions-nous l’intégrité ? »
A09 : carences de journalisation et de supervision
En clair : il se passe quelque chose d’anormal, et personne ne le voit. Cette catégorie n’est pas une faille en soi : c’est ce qui transforme un incident mineur en incident majeur, faute de détection et de capacité d’investigation.
La question à poser : « Si un compte administrateur était compromis aujourd’hui, quelles traces nous permettraient de reconstituer ce qui a été consulté, et pendant combien de temps sont-elles conservées ? »
A10 : falsification de requête côté serveur (SSRF)
En clair : votre serveur est amené à effectuer une requête vers une adresse choisie par l’utilisateur, ce qui permet d’atteindre des ressources internes normalement inaccessibles depuis Internet. Cette catégorie a été ajoutée en raison de sa fréquence croissante dans les architectures cloud.
La question à poser : « Quelles fonctionnalités acceptent une URL fournie par l’utilisateur, et comment les destinations autorisées sont-elles restreintes ? »
Comment s’en servir sans le déformer
Trois précautions d’usage.
Ce n’est pas une checklist de conformité. Aucune organisation n’est « conforme OWASP Top 10 ». On peut en revanche démontrer que chaque catégorie a été examinée et documentée pour une application donnée.
Ce n’est pas exhaustif. Beaucoup de failles réelles relèvent de la logique métier propre à un produit (un parcours de facturation détournable, un mécanisme d’invitation qui accorde trop de droits) sans entrer nettement dans une des dix cases.
Le classement n’est pas une priorisation pour vous. L’ordre reflète des statistiques globales. Sur votre application, une catégorie classée huitième peut représenter le risque principal.
Utilisé comme grille de revue lors de la conception d’une fonctionnalité sensible, en dix questions posées à voix haute, le Top 10 remplit en revanche parfaitement son rôle : il structure une discussion que peu d’équipes ont spontanément.
