OWASP Top 10 : les risques de sécurité web à connaître en 2025

Pourquoi la sécurité web n’est plus une option en 2025

En 2024, le coût moyen d’une violation de données a atteint 4,88 millions de dollars selon le rapport IBM Cost of a Data Breach. En France, l’ANSSI a recensé une augmentation de 30 % des cyberattaques ciblant les PME entre 2022 et 2024. Que vous gériez un site vitrine, un blog WordPress ou une boutique Prestashop, les menaces sont réelles et les conséquences potentiellement désastreuses : vol de données clients, perte de chiffre d’affaires, atteinte à la réputation, sanctions RGPD.

Face à cette réalité, un référentiel s’est imposé comme la boussole universelle de la sécurité applicative web : le OWASP Top 10. Publié par l’Open Web Application Security Project — une fondation à but non lucratif regroupant des milliers d’experts bénévoles — ce classement identifie les 10 catégories de risques les plus critiques auxquelles sont exposées les applications web.

Dans cet article, nous passons en revue chacune de ces vulnérabilités, avec des exemples concrets, des extraits de code et surtout des solutions pratiques pour protéger votre site.

Le OWASP Top 10 en un coup d’œil

Avant de plonger dans le détail, voici un tableau récapitulatif du classement OWASP Top 10 dans sa dernière version (2021, toujours en vigueur en 2025) :

Rang	Catégorie	Évolution vs 2017
A01	Broken Access Control (Contrôle d’accès défaillant)	↑ Monté de la 5e place
A02	Cryptographic Failures (Défauts cryptographiques)	↑ Anciennement “Exposition de données sensibles”
A03	Injection (SQL, NoSQL, LDAP, etc.)	↓ Descendu de la 1re place
A04	Insecure Design (Conception non sécurisée)	🆕 Nouveau
A05	Security Misconfiguration (Mauvaise configuration)	↑ Monté de la 6e place
A06	Vulnerable and Outdated Components (Composants vulnérables)	↑ Monté de la 9e place
A07	Identification and Authentication Failures	↓ Descendu de la 2e place
A08	Software and Data Integrity Failures	🆕 Nouveau
A09	Security Logging and Monitoring Failures	↑ Monté de la 10e place
A10	Server-Side Request Forgery (SSRF)	🆕 Nouveau

On constate que les injections SQL, historiquement en tête, ont cédé la première place au contrôle d’accès défaillant. Trois nouvelles catégories ont fait leur apparition, reflétant l’évolution des menaces.

A01 – Contrôle d’accès défaillant (Broken Access Control)

De quoi s’agit-il ?

Le contrôle d’accès garantit que les utilisateurs ne peuvent effectuer que les actions autorisées par leur rôle. Quand ce mécanisme est défaillant, un simple utilisateur peut accéder à des données administrateur, modifier les comptes d’autres utilisateurs ou supprimer des contenus.

Exemple concret

Imaginons une URL d’administration comme https://monsite.com/admin/users?id=42. Si un attaquant modifie simplement le paramètre en ?id=1, il pourrait accéder au compte administrateur principal. C’est ce qu’on appelle une IDOR (Insecure Direct Object Reference).

Comment s’en protéger

• Appliquer le principe du moindre privilège par défaut
• Vérifier les autorisations côté serveur à chaque requête
• Désactiver le listing des répertoires
• Journaliser et alerter sur les échecs d’accès répétés

A02 – Défauts cryptographiques (Cryptographic Failures)

De quoi s’agit-il ?

Cette catégorie couvre les faiblesses liées au chiffrement des données : mots de passe stockés en clair, certificats SSL/TLS expirés, algorithmes de hashage obsolètes (MD5, SHA-1), clés de chiffrement codées en dur dans le code source.

Chiffres clés

Selon le rapport Verizon DBIR 2024, 17 % des violations de données impliquent des défaillances cryptographiques. Beaucoup de sites e-commerce stockent encore des informations de carte bancaire avec un chiffrement insuffisant.

Bonnes pratiques

• Utiliser TLS 1.3 pour toutes les communications
• Hasher les mots de passe avec bcrypt ou Argon2 (jamais MD5)
• Ne jamais stocker de données sensibles inutilement
• Gérer les clés de chiffrement via un gestionnaire dédié (AWS KMS par exemple)

Chez Lueur Externe, notre certification AWS Solutions Architect nous permet de déployer des architectures cloud où le chiffrement est appliqué de bout en bout : au repos, en transit et en mémoire.

A03 – Injection (SQL, NoSQL, XSS, etc.)

De quoi s’agit-il ?

L’injection reste l’une des attaques les plus dévastatrices. Elle survient lorsque des données non fiables sont envoyées à un interpréteur (SQL, commandes OS, LDAP) sans validation ni échappement.

Exemple de code vulnérable vs sécurisé

Voici un exemple en PHP, courant sur des sites WordPress ou Prestashop mal développés :

// ❌ VULNÉRABLE : injection SQL possible
$query = "SELECT * FROM users WHERE id = " . $_GET['id'];
$result = mysqli_query($conn, $query);

// ✅ SÉCURISÉ : requête préparée avec paramètres liés
$stmt = $conn->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $_GET['id']);
$stmt->execute();
$result = $stmt->get_result();

Dans le premier cas, un attaquant peut injecter 1 OR 1=1 -- pour récupérer tous les utilisateurs de la base de données. Dans le second cas, le paramètre est correctement typé et isolé.

Mesures de protection

• Toujours utiliser des requêtes préparées (parameterized queries)
• Valider et assainir toutes les entrées utilisateur côté serveur
• Utiliser un WAF (Web Application Firewall) comme couche de protection supplémentaire
• Appliquer le principe du moindre privilège aux comptes de base de données

A04 – Conception non sécurisée (Insecure Design)

Une nouveauté importante

Cette catégorie, apparue en 2021, marque un tournant : l’OWASP reconnaît que la sécurité ne peut pas se limiter à corriger des bugs. Elle doit être intégrée dès la phase de conception (Security by Design).

Un site e-commerce qui ne limite pas le nombre de tentatives de mot de passe souffre d’un défaut de conception, pas d’un bug technique. Un formulaire de récupération de mot de passe qui confirme l’existence d’un email est un défaut d’architecture.

Recommandations

• Intégrer la modélisation des menaces (Threat Modeling) dès le cahier des charges
• Rédiger des user stories abusives : “En tant qu’attaquant, je tente de…”
• Séparer les environnements de développement, test et production
• Effectuer des revues de conception sécurité avant le développement

A05 – Mauvaise configuration de sécurité (Security Misconfiguration)

Le risque le plus fréquent

C’est sans doute la vulnérabilité la plus répandue car elle touche tous les niveaux : serveur web, base de données, framework, CMS, cloud. Des exemples classiques :

• Pages d’erreur affichant des traces de pile (stack traces) en production
• Comptes par défaut non désactivés (admin/admin)
• Headers HTTP de sécurité manquants
• Buckets S3 AWS accessibles publiquement
• Mode debug activé en production sur WordPress ou Prestashop

Headers de sécurité essentiels

Un serveur web correctement configuré devrait envoyer au minimum ces headers :

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Un outil comme Mozilla Observatory permet de tester gratuitement la configuration de vos headers en quelques secondes.

A06 – Composants vulnérables et obsolètes

Un site WordPress moyen utilise entre 20 et 30 plugins. Chaque plugin est un vecteur d’attaque potentiel. Selon WPScan, 97 % des vulnérabilités WordPress proviennent des extensions tierces.

De même, un site Prestashop dont les modules ne sont pas mis à jour expose ses clients à des risques majeurs : vol de données bancaires, injection de code malveillant dans les pages de paiement.

Actions concrètes

• Mettre en place une veille de vulnérabilités (CVE, base NVD)
• Automatiser les mises à jour de sécurité
• Supprimer les plugins, thèmes et modules non utilisés
• Utiliser des outils comme Dependabot, Snyk ou WPScan

A07 – Défaillances d’identification et d’authentification

Mots de passe faibles, absence de limitation de tentatives, sessions qui n’expirent jamais, tokens prévisibles… Les failles d’authentification permettent à un attaquant de se faire passer pour un utilisateur légitime.

Le minimum à implémenter

• Authentification multi-facteurs (MFA) pour les accès administratifs
• Politique de mots de passe robuste (12 caractères minimum, complexité)
• Limitation du nombre de tentatives (rate limiting + CAPTCHA)
• Rotation et invalidation correcte des tokens de session

A08 – Défaillances d’intégrité des logiciels et des données

Cette catégorie couvre les risques liés aux mises à jour non vérifiées, aux pipelines CI/CD compromis et à la désérialisation non sécurisée. L’attaque SolarWinds de 2020 est l’exemple le plus marquant : des attaquants ont injecté du code malveillant directement dans le processus de mise à jour du logiciel, touchant 18 000 organisations dont des agences gouvernementales américaines.

Mesures de protection

• Vérifier l’intégrité des dépendances via des signatures numériques
• Sécuriser le pipeline CI/CD (accès, logs, séparation des environnements)
• Éviter la désérialisation de données non fiables

A09 – Insuffisance de journalisation et de surveillance

Selon IBM, le délai moyen pour détecter une violation de données est de 194 jours en 2024. Sans logs correctement configurés et sans monitoring en temps réel, une attaque peut passer totalement inaperçue pendant des mois.

Ce qu’il faut journaliser

• Toutes les tentatives de connexion (réussies et échouées)
• Les accès aux fonctions d’administration
• Les modifications de données sensibles
• Les erreurs serveur inhabituelles

Les logs doivent être centralisés, horodatés et protégés contre la modification. Des solutions comme AWS CloudWatch, ELK Stack ou Datadog permettent d’automatiser la détection d’anomalies.

A10 – Server-Side Request Forgery (SSRF)

La menace émergente

Le SSRF permet à un attaquant de forcer le serveur à effectuer des requêtes vers des ressources internes normalement inaccessibles depuis l’extérieur. Avec la généralisation du cloud et des architectures microservices, ce risque a explosé.

L’attaque Capital One de 2019, qui a exposé les données de 106 millions de clients, reposait sur une vulnérabilité SSRF permettant d’accéder aux métadonnées des instances AWS EC2.

Protections

• Valider et restreindre les URL côté serveur (liste blanche)
• Segmenter le réseau pour limiter les accès depuis les serveurs applicatifs
• Désactiver les redirections HTTP non nécessaires
• Bloquer l’accès aux métadonnées cloud (169.254.169.254) depuis l’application

Comment mettre en pratique le OWASP Top 10 sur votre site

Connaître les risques, c’est bien. Agir concrètement, c’est mieux. Voici une feuille de route pragmatique en 5 étapes :

1. Auditer l’existant : scanner votre site avec des outils comme OWASP ZAP, Nikto ou Burp Suite
2. Prioriser les corrections : traiter d’abord les vulnérabilités critiques (A01 à A03)
3. Former les équipes : sensibiliser développeurs et administrateurs aux bonnes pratiques
4. Automatiser la sécurité : intégrer des tests de sécurité dans le pipeline de déploiement
5. Surveiller en continu : mettre en place un monitoring actif et des alertes

L’équipe de Lueur Externe, forte de plus de 20 ans d’expérience en développement web et en infogérance serveur, accompagne ses clients dans chacune de ces étapes. De l’audit initial à la mise en conformité, en passant par la configuration des environnements AWS, WordPress et Prestashop, chaque couche technique est passée au crible.

Les erreurs les plus courantes que nous rencontrons

Après des centaines d’audits réalisés depuis 2003, les spécialistes de Lueur Externe constatent que certaines erreurs reviennent systématiquement :

• WordPress en version obsolète avec le fichier xmlrpc.php activé (vecteur de brute force)
• Prestashop avec des modules piratés (“nulled”) contenant des backdoors
• Certificats SSL auto-signés ou mal configurés sur des boutiques en ligne
• Aucun header de sécurité configuré sur le serveur web
• Backups de base de données accessibles publiquement via l’URL
• Comptes FTP avec mots de passe faibles et sans restriction IP

Chacune de ces erreurs peut être exploitée en quelques minutes par un attaquant déterminé.

Conclusion : la sécurité web est un investissement, pas une dépense

Le OWASP Top 10 n’est pas une simple liste théorique. C’est un cadre de travail concret qui permet d’évaluer, prioriser et corriger les vulnérabilités les plus dangereuses de votre site web. Que vous soyez propriétaire d’un site vitrine, d’un blog ou d’une boutique e-commerce traitant des milliers de transactions, ces 10 catégories de risques vous concernent directement.

La bonne nouvelle ? La majorité de ces vulnérabilités sont évitables avec les bonnes pratiques de développement, une configuration serveur rigoureuse et un suivi régulier.

Ne laissez pas la sécurité de votre site au hasard. Contactez les experts de Lueur Externe pour un audit complet de votre application web, une mise en conformité OWASP et un accompagnement sur mesure adapté à votre infrastructure. Avec plus de 20 ans d’expertise en développement web sécurisé et une maîtrise des environnements WordPress, Prestashop et AWS, nous avons les compétences pour protéger durablement votre activité en ligne.