L'OWASP Top 10, en français clair.
L'OWASP Top 10 est la référence mondiale des risques de sécurité des applications web. Le problème : elle est écrite par des techniciens, pour des techniciens. Voici une traduction honnête pour les dirigeants : ce que chaque risque veut dire, ce qui se passe quand il se réalise, et la bonne question à poser à votre équipe ou à votre prestataire.
C'est quoi l'OWASP Top 10, et pourquoi ça vous concerne
L'OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie, depuis plus de vingt ans, un classement des dix risques de sécurité les plus critiques pour les applications web. C'est la référence : assureurs cyber, auditeurs et donneurs d'ordre s'y appuient.
Vous n'avez pas besoin de comprendre techniquement chaque risque. Vous devez savoir qu'ils existent, reconnaître celui qui vous menace, et surtout : poser les bonnes questions. Un prestataire sérieux saura y répondre clairement. Un prestataire qui élude, c'est déjà une réponse.
Contrôle d'accès défaillant
Ce que c'est. Un utilisateur peut accéder à des données ou des actions qui ne devraient pas lui être permises — voir le dossier d'un autre client, passer admin, modifier une commande qui n'est pas la sienne.
Le risque concret. Fuite de données clients, manipulation de commandes, prise de contrôle de comptes. C'est, année après année, le risque le plus répandu.
help « Qui peut voir et faire quoi sur notre application, et comment on le vérifie ? »
Échecs cryptographiques
Ce que c'est. Des données sensibles (mots de passe, données bancaires, données personnelles) sont mal protégées : transmises en clair, stockées sans chiffrement correct, ou avec des méthodes dépassées.
Le risque concret. En cas de fuite, tout est lisible directement. Et sous RGPD/nLPD, le défaut de chiffrement aggrave votre responsabilité.
help « Nos données sensibles sont-elles chiffrées en transit et au repos ? »
Injection
Ce que c'est. L'application fait confiance à ce que tape l'utilisateur et le passe tel quel à sa base de données ou son système. Un attaquant glisse alors des commandes au lieu de simples données.
Le risque concret. Vol ou destruction de toute la base, contournement de l'authentification. Un grand classique, toujours d'actualité.
help « Nos formulaires et champs de recherche valident-ils correctement ce qui est saisi ? »
Conception non sécurisée
Ce que c'est. Le problème n'est pas un bug, mais un défaut pensé en amont : un parcours qui oublie une vérification, une logique métier exploitable (réinitialiser un mot de passe sans preuve, commander à prix négatif).
Le risque concret. Impossible à corriger par un simple patch — il faut repenser la fonctionnalité. D'où l'intérêt d'y penser dès la conception.
help « A-t-on réfléchi à comment quelqu'un pourrait détourner cette fonctionnalité ? »
Mauvaise configuration
Ce que c'est. Réglages par défaut laissés en place, comptes de test oubliés, messages d'erreur trop bavards, panneaux d'administration accessibles, permissions trop larges.
Le risque concret. Souvent la porte la plus facile : pas besoin d'exploiter une faille, il suffit de pousser une porte restée ouverte.
help « A-t-on retiré tout ce qui était en mode démo / par défaut avant la mise en production ? »
Composants vulnérables et obsolètes
Ce que c'est. Votre site repose sur des briques tierces (CMS, plugins, librairies). Quand l'une a une faille connue et n'est pas mise à jour, vous héritez de sa vulnérabilité.
Le risque concret. Les attaques de masse ciblent précisément les versions vulnérables connues — c'est le vecteur n°1 sur WordPress et WooCommerce.
help « Qui suit les mises à jour de sécurité de nos composants, et à quelle fréquence ? »
Identification et authentification défaillantes
Ce que c'est. Connexion trop permissive : mots de passe faibles tolérés, pas de second facteur, sessions qui ne expirent jamais, pas de limite aux tentatives.
Le risque concret. Prise de comptes par force brute ou identifiants volés ailleurs. C'est ce qui transforme une fuite externe en intrusion chez vous.
help « Avons-nous le 2FA et une vraie politique de mots de passe sur les comptes sensibles ? »
Défauts d'intégrité logicielle
Ce que c'est. L'application fait confiance à du code, des mises à jour ou des données venues d'une source non vérifiée — une dépendance compromise, une mise à jour non signée.
Le risque concret. Un seul maillon piégé dans la chaîne d'approvisionnement logicielle peut contaminer tout le système.
help « D'où vient le code qu'on installe, et comment on s'assure qu'il n'est pas piégé ? »
Journalisation et supervision insuffisantes
Ce que c'est. Il ne se passe rien de visible quand quelqu'un attaque : pas de logs utiles, pas d'alerte, personne qui regarde.
Le risque concret. C'est ce qui explique les 6 mois entre la compromission et sa découverte. On ne peut pas réagir à ce qu'on ne voit pas.
help « Si on nous attaquait maintenant, est-ce qu'on le saurait — et sous combien de temps ? »
Falsification de requête côté serveur (SSRF)
Ce que c'est. L'application peut être manipulée pour aller chercher elle-même des ressources internes qu'un attaquant ne pourrait pas atteindre directement (services internes, métadonnées cloud).
Le risque concret. Accès à des systèmes internes normalement protégés, fuite de secrets d'infrastructure cloud.
help « Notre application contrôle-t-elle les adresses vers lesquelles elle se connecte ? »
Ce que vous, dirigeant, pouvez faire
Vous ne corrigerez pas ces failles vous-même, et c'est normal. Mais vous tenez les leviers qui comptent :
- Exiger des réponses claires à votre prestataire ou équipe sur les questions ci-dessus. La clarté de la réponse est un bon indicateur de sérieux.
- Imposer les mises à jour comme une ligne budgétaire récurrente, pas un « quand on aura le temps ». La majorité des intrusions exploitent du connu, non corrigé.
- Activer le 2FA sur tous les accès sensibles — c'est la mesure au meilleur rapport effort/protection.
- Faire auditer périodiquement l'application par un œil extérieur. On ne voit pas ses propres angles morts.
- Vous assurer qu'on regarde les logs — pas seulement qu'on les produit (le A09 est le plus silencieux et le plus coûteux).