Retour au blog
webOWASPguide2026

Vulnérabilités web : le guide complet OWASP Top 10 pour 2026

Publié le 2026-04-019 min de lectureFlorian

Pourquoi l'OWASP Top 10 reste la référence en 2026

L'OWASP Top 10 est le classement de référence des vulnérabilités applicatives web. Publié par l'Open Web Application Security Project, il est mis à jour tous les trois à quatre ans. La dernière version officielle date de 2021, mais les catégories restent pleinement pertinentes en 2026. Chez CleanIssue, chaque revue externe commence par une vérification systématique de ces dix catégories.

A01 : Broken Access Control

C'est la vulnérabilité numéro un depuis 2021. Elle regroupe les IDOR, les accès horizontaux et verticaux non contrôlés, et les contournements de restrictions. En pratique, un utilisateur lambda accède aux données d'un autre utilisateur en modifiant un paramètre dans l'URL ou dans le corps de la requête. Exemple : GET /api/invoices/1042 renvoie la facture d'un autre client si aucun contrôle côté serveur ne vérifie l'appartenance.

Ce qu'on vérifie : chaque endpoint exposé est testé avec un utilisateur non propriétaire de la ressource.

A02 : Cryptographic Failures

Anciennement Sensitive Data Exposure. Cela couvre le stockage en clair de mots de passe, l'absence de TLS sur les flux sensibles, les algorithmes de hachage obsolètes comme MD5 ou SHA1 sans sel. On trouve encore des applications qui stockent des tokens dans localStorage sans chiffrement et qui transmettent des données médicales sur HTTP.

A03 : Injection

L'injection SQL reste présente, mais cette catégorie couvre aussi les injections NoSQL, LDAP, OS command et ORM. Toute donnée utilisateur insérée dans une requête sans paramétrage est un vecteur. Les ORM modernes réduisent le risque mais ne l'éliminent pas : les requêtes brutes dans Laravel (DB::raw()) ou Django (extra()) restent dangereuses.

A04 : Insecure Design

Ajouté en 2021, ce point cible les failles de conception. Un système de réinitialisation de mot de passe qui utilise un code à 4 chiffres sans limitation de tentatives n'est pas un bug d'implémentation, c'est un défaut de conception. Aucun correctif technique ne compense une architecture pensée sans modèle de menaces.

A05 : Security Misconfiguration

Les headers HTTP manquants (X-Frame-Options, Content-Security-Policy), les pages d'erreur verbeuses, les fonctionnalités de debug activées en production, les permissions par défaut trop larges sur les buckets S3 ou les bases Supabase sans RLS. C'est la catégorie la plus fréquente dans nos audits de PME.

A06 : Vulnerable and Outdated Components

Utiliser une version de jQuery avec une XSS connue, un plugin WordPress non maintenu depuis deux ans, ou une image Docker basée sur un OS en fin de vie. La gestion des dépendances est un processus continu, pas un événement ponctuel.

A07 : Identification and Authentication Failures

Sessions qui ne s'invalident pas à la déconnexion, absence de protection contre le brute force, tokens JWT sans expiration, mots de passe faibles acceptés. On trouve régulièrement des applications qui acceptent password123 comme mot de passe valide.

A08 : Software and Data Integrity Failures

Cette catégorie inclut les pipelines CI/CD non sécurisées et la désérialisation non sûre. Un attaquant qui compromet un paquet npm utilisé par votre application peut injecter du code arbitraire. C'est exactement ce qui s'est passé avec event-stream en 2018 et xz-utils en 2024.

A09 : Security Logging and Monitoring Failures

Si personne ne détecte une intrusion, l'attaquant opère librement. Pas de logs d'authentification, pas d'alertes sur les erreurs 403 massives, pas de surveillance des accès API anormaux. La majorité des PME que nous auditons n'ont aucun système de détection.

A10 : Server-Side Request Forgery (SSRF)

L'attaquant force le serveur à émettre des requêtes vers des ressources internes. En environnement cloud, cela permet souvent d'atteindre le service de métadonnées (169.254.169.254) et de récupérer des identifiants IAM. C'est la faille qui a permis la compromission de Capital One en 2019.

Par où commencer

Avant de lancer un scanner, vérifiez manuellement les cinq premières catégories. Elles représentent plus de 80% des failles critiques que nous trouvons. Un revue externe CleanIssue couvre systématiquement les dix catégories. Parlez-nous de votre revue externe pour connaître votre exposition.

Articles liés

Trois analyses proches pour continuer la lecture sur la meme surface de risque.

Sources

Rédigé par Florian
Revu le 2026-04-01

Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.

Services associés

Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.

Besoin d'une revue externe de votre SaaS RH ?

Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

Parler de votre audit