OWASP Top 10 expliqué avec des exemples pratiques

Security2026-09-11TryQuickToolBox

Chaque année, des milliers d'applications web sont compromises en raison des mêmes failles de sécurité récurrentes. Le Top 10 OWASP est un document de sensibilisation standard qui répertorie les risques de sécurité les plus critiques pour les applications web. Dans cet article, nous allons passer en revue chaque risque, montrer un exemple pratique et expliquer comment l'atténuer. Que vous soyez développeur, ingénieur DevOps ou passionné de sécurité, comprendre ces risques est essentiel pour construire des systèmes sécurisés.

1. Contrôle d'accès défaillant

Le contrôle d'accès défaillant se produit lorsque les utilisateurs peuvent agir en dehors de leurs permissions prévues. Par exemple, un utilisateur peut accéder aux données d'un autre utilisateur en modifiant un paramètre d'URL.

Exemple : Une application utilise /api/user/123 pour récupérer les données d'un utilisateur. S'il n'y a pas de vérification que l'utilisateur connecté est bien l'utilisateur 123, un attaquant peut changer l'ID en /api/user/124 et consulter le profil de quelqu'un d'autre.

Atténuation : Mettez en place des contrôles d'accès côté serveur. Refusez par défaut. Utilisez le contrôle d'accès basé sur les rôles (RBAC) et validez les permissions à chaque requête.

2. Défaillances cryptographiques

Anciennement appelé « Exposition de données sensibles », ce risque consiste à ne pas protéger les données sensibles en transit ou au repos.

Exemple : Stocker des mots de passe en clair ou utiliser des algorithmes de hachage faibles comme MD5.

Atténuation : Utilisez un chiffrement fort (par exemple AES-256) pour les données au repos, TLS 1.2+ pour les données en transit, et un hachage de mot de passe robuste (bcrypt, Argon2).

3. Injection

Les failles d'injection, telles que l'injection SQL, NoSQL, OS et LDAP, se produisent lorsque des données non fiables sont envoyées à un interpréteur dans le cadre d'une commande ou d'une requête.

Exemple : Un formulaire de connexion qui construit une requête SQL comme :

SELECT * FROM users WHERE username = '$username' AND password = '$password';

Si un attaquant saisit ' OR '1'='1 comme nom d'utilisateur, il peut contourner l'authentification.

Atténuation : Utilisez des requêtes paramétrées ou des instructions préparées. Échappez les caractères spéciaux et validez les entrées.

4. Conception non sécurisée

La conception non sécurisée fait référence à des failles dans l'architecture et la conception d'une application, et non seulement à des bugs d'implémentation.

Exemple : Une fonctionnalité de réinitialisation de mot de passe qui utilise des questions de sécurité avec des réponses faciles à deviner.

Atténuation : Modélisation des menaces lors de la conception, modèles de conception sécurisés et architectures de référence.

5. Mauvaise configuration de sécurité

Cela inclut les comptes par défaut, les pages inutilisées, les failles non corrigées, les fichiers et répertoires non protégés.

Exemple : Laisser les identifiants administrateur par défaut sur un CMS ou exposer les listages de répertoires.

Atténuation : Durcissez les configurations, supprimez les fonctionnalités inutilisées et automatisez les vérifications de configuration.

6. Composants vulnérables et obsolètes

Utiliser des bibliothèques, frameworks ou logiciels présentant des vulnérabilités connues.

Exemple : Exécuter une ancienne version d'une bibliothèque JavaScript avec une vulnérabilité XSS connue.

Atténuation : Mettez régulièrement à jour les dépendances, utilisez des outils comme npm audit ou OWASP Dependency-Check, et supprimez les dépendances inutilisées.

7. Défaillances d'identification et d'authentification

Faiblesses dans l'authentification et la gestion de session.

Exemple : Autoriser des mots de passe faibles, l'absence de limitation du taux de tentatives de connexion, ou exposer les identifiants de session dans les URL.

Atténuation : Implémentez l'authentification multifacteur, appliquez des politiques de mots de passe forts et utilisez une gestion de session sécurisée.

8. Défaillances d'intégrité des logiciels et des données

Code et infrastructure qui ne protègent pas contre les violations d'intégrité.

Exemple : Utiliser des CDN non fiables pour les scripts sans Subresource Integrity (SRI).

Atténuation : Utilisez SRI, vérifiez les signatures et assurez-vous que les pipelines CI/CD sont sécurisés.

9. Défaillances de journalisation et de surveillance de sécurité

Une journalisation et une surveillance insuffisantes permettent aux attaquants de persister sans être détectés.

Exemple : Ne pas journaliser les tentatives de connexion échouées, de sorte que les attaques par force brute passent inaperçues.

Atténuation : Journalisez les événements liés à la sécurité, surveillez les journaux et configurez des alertes pour les activités suspectes.

10. Falsification de requête côté serveur (SSRF)

La SSRF se produit lorsqu'un attaquant peut amener le serveur à effectuer des requêtes vers des ressources internes.

Exemple : Une fonctionnalité de webhook qui récupère une URL fournie par l'utilisateur. Un attaquant pourrait fournir http://169.254.169.254/latest/meta-data/ pour accéder aux métadonnées du cloud.

Atténuation : Validez et assainissez les URL, utilisez des listes d'autorisation et restreignez le trafic sortant.

Tableau comparatif

RisqueExempleAtténuation
Contrôle d'accès défaillantAccéder aux données d'un autre utilisateur via IDORVérifications de permissions côté serveur
Défaillances cryptographiquesStocker des mots de passe en clairUtiliser un hachage fort et TLS
InjectionInjection SQL via un formulaire de connexionRequêtes paramétrées
Conception non sécuriséeQuestions de réinitialisation de mot de passe faiblesModélisation des menaces
Mauvaise configuration de sécuritéIdentifiants administrateur par défautDurcir les configurations
Composants vulnérablesAncienne bibliothèque avec faille XSSMises à jour régulières
Défaillances d'authentificationPas de limitation de taux à la connexionMFA et limitation de taux
Défaillances d'intégritéScripts CDN non fiablesSubresource Integrity
Défaillances de journalisationAucun journal pour les connexions échouéesJournalisation centralisée et alertes
SSRFRécupérer des métadonnées internesListes d'autorisation d'URL

Comment démarrer

  1. Évaluer : Exécutez des scanners automatisés et des revues manuelles par rapport au Top 10 OWASP.
  2. Prioriser : Corrigez d'abord les problèmes les plus critiques (par exemple, injection, contrôle d'accès défaillant).
  3. Former : Sensibilisez les développeurs aux pratiques de codage sécurisé.
  4. Surveiller : Mettez en place la journalisation et les alertes pour les événements de sécurité.
  5. Itérer : Mettez régulièrement à jour les dépendances et retestez.

FAQ

Qu'est-ce que le Top 10 OWASP ?

Le Top 10 OWASP est une liste régulièrement mise à jour des risques de sécurité les plus critiques pour les applications web, publiée par l'Open Web Application Security Project (OWASP).

À quelle fréquence le Top 10 OWASP est-il mis à jour ?

Il est mis à jour environ tous les trois à quatre ans, la dernière version ayant été publiée en 2021. Cependant, OWASP fournit des conseils et des mises à jour continues.

Puis-je me fier uniquement au Top 10 OWASP pour la sécurité ?

Non, c'est un point de départ. Vous devriez également suivre d'autres projets OWASP comme l'Application Security Verification Standard (ASVS) et effectuer des tests de sécurité réguliers.

Pour analyser rapidement vos journaux Nginx à la recherche de signes d'attaques comme l'injection SQL ou XSS, essayez notre Analyseur de journaux Nginx. Il vous aide à repérer les schémas suspects et à sécuriser votre serveur web.