OWASP Top 10 expliqué simplement : les 10 failles qui menacent votre site en 2026

TL;DR

L'OWASP Top 10 est la liste de référence des 10 familles de failles web les plus critiques. Mise à jour régulièrement par la communauté sécurité mondiale, elle structure 90 % du travail d'un pentester. Voici les 10 expliquées simplement, avec ce qu'elles peuvent provoquer concrètement chez vous et les actions de défense de base.

OWASP Top 10, c''est quoi exactement ?

L''OWASP (Open Web Application Security Project) est une fondation à but non lucratif qui publie depuis 2003 un classement des 10 familles de vulnérabilités les plus critiques sur les applications web. La version actuelle (2021, mise à jour partielle en 2024) sert de référence à TOUS les pentesters professionnels et à la plupart des audits sécurité.

Pour une PME, comprendre l''OWASP Top 10 a un intérêt très concret : ça vous dit ce que cherche un attaquant ou un pentester quand il regarde votre site. Pas besoin de savoir le code derrière, juste de comprendre les catégories de failles pour pouvoir poser les bonnes questions à votre développeur ou à votre prestataire.

Les 10 familles sont volontairement larges. On va les passer dans l''ordre, avec un exemple concret de ce qui peut vous arriver et la défense de base.

1 à 5 : les 5 plus dévastatrices

1. Broken Access Control — accès non maîtrisé

Ce que c''est : un utilisateur peut accéder à des données ou fonctions qui ne lui appartiennent pas. Le cas classique : changer 123 en 124 dans une URL et voir la facture du voisin.

Cas réel PME : un site de prise de rendez-vous médical où l''URL /rdv/45678 permettait de voir la fiche d''un autre patient en changeant le numéro.

Défense : chaque endpoint doit vérifier que l''utilisateur connecté a le droit d''accéder à la ressource demandée. Pas juste « il est connecté ».

2. Cryptographic Failures — chiffrement faible ou absent

Ce que c''est : des données sensibles (mots de passe, données personnelles, paiements) circulent ou sont stockées sans chiffrement, ou avec un chiffrement obsolète.

Cas réel PME : un e-commerce qui stockait les mots de passe en MD5 (cassé depuis 2005). Un dump de base est devenu un fichier en clair pour l''attaquant.

Défense : HTTPS partout (cf. notre article SSL), bcrypt ou Argon2 pour les mots de passe, pas de stockage de données de carte bancaire.

3. Injection — l''attaquant dicte le code à exécuter

Ce que c''est : une donnée envoyée par l''utilisateur est interprétée comme une commande par le serveur. Le cas le plus connu : SQL Injection (SQLi). Mais il y a aussi NoSQL injection, command injection, LDAP injection.

Cas réel : un formulaire de recherche qui prend nom_client et l''insère directement dans une requête SQL. L''attaquant tape '; DROP TABLE clients; -- et la table disparaît.

Défense : requêtes préparées (paramétrées) systématiquement, jamais de concaténation de chaîne.

4. Insecure Design — failles de conception

Ce que c''est : une fonctionnalité dont la logique métier est fragile. Pas une erreur de code, une erreur de design.

Cas réel : un site de e-commerce qui permettait d''ajouter une quantité négative de produit dans le panier, ce qui crédite le compte.

Défense : revue de design avant développement. Penser "qu''est-ce qu''un attaquant peut faire avec cette feature ?".

5. Security Misconfiguration — config oubliée

Ce que c''est : un mot de passe par défaut, un panneau d''admin accessible sans authentification, un message d''erreur qui révèle la version du serveur.

Cas réel : un dashboard admin Kibana exposé sur Internet sans mot de passe — découvert via Shodan.

Défense : durcir la config par défaut (cf. OWASP Cheat Sheet Hardening). L''audit CyberTool vérifie automatiquement les en-têtes HTTP et les bannières serveur exposées.

6 à 10 : les 5 plus subtiles

6. Vulnerable and Outdated Components

Ce que c''est : vous utilisez une librairie ou un plugin avec une CVE connue et non corrigée. Cas le plus fréquent en 2026 : un plugin WordPress pas à jour.

Défense : patch management discipliné. Outil comme Dependabot (gratuit) pour les projets, mises à jour auto WordPress.

7. Identification and Authentication Failures

Ce que c''est : mots de passe faibles autorisés, pas de MFA, pas de blocage après plusieurs échecs.

Défense : politique de mot de passe (12+ caractères, pas de mots de dictionnaire), MFA obligatoire pour les comptes admin, rate limiting sur le login.

8. Software and Data Integrity Failures

Ce que c''est : vous chargez du code depuis une source non vérifiée (CDN compromis, plugin sans signature).

Défense : SRI (Subresource Integrity) sur les scripts externes, vérifier les sommes de contrôle des plugins, supply chain security.

9. Security Logging and Monitoring Failures

Ce que c''est : vous ne loggez pas assez, ou vous ne lisez jamais les logs. Vous découvrez 6 mois plus tard que l''attaquant est dans votre système depuis avril.

Défense : logger les événements critiques (login, changement de mot de passe, accès admin), centraliser, mettre en place une alerte sur les patterns suspects.

10. Server-Side Request Forgery (SSRF)

Ce que c''est : votre serveur fait une requête HTTP vers une URL fournie par l''utilisateur, et l''attaquant l''utilise pour scanner votre réseau interne.

Défense : ne jamais accepter d''URL utilisateur sans whitelisting strict. Si vraiment nécessaire, valider la résolution DNS et refuser les IP privées (10.x, 192.168.x, 172.16-31.x).

Comment savoir où vous en êtes vraiment ?

Trois niveaux d''audit, par ordre de profondeur :

1. Audit automatisé externe (gratuit) : CyberTool, Mozilla Observatory, SSL Labs. Couvre 5/10 des catégories OWASP côté infrastructure (HTTPS, en-têtes, expositions évidentes). 5 minutes, à faire chaque mois.
2. Scan applicatif automatisé : OWASP ZAP (gratuit), Burp Community, Nikto. Crawle votre site et teste des patterns d''attaque connus. Quelques heures à configurer, faux positifs à filtrer.
3. Pentest manuel par un consultant : 2-5 jours de travail, entre 3 000 et 15 000 €. C''est le seul moyen de trouver les failles métier (logique business) que les outils automatiques ratent. À envisager pour un site e-commerce qui traite plus de 100k€/an de chiffre d''affaires.

Pour 80 % des PME, faire le 1 chaque mois et le 2 une fois par an suffit largement. Le 3 devient pertinent quand le risque financier le justifie.

Frequently asked questions

Related reading

• 🌐 Veille
  5 groupes ransomware français à bloquer maintenant (mai 2026)
• 📡 Détection
  Détecter un ransomware avant le chiffrement: 3 signaux à surveiller en 2026
• 🚨 Incident
  Cyberattaque : que faire dans les 24 premières heures (plan d'action PME)