OWASP Top 10 2025 - Comprendre les risques majeurs pour vos applications

L’OWASP Top 10 est un classement des risques de sécurité les plus récurrents et impactants pour les applications web, maintenu par l’Open Worldwide Application Security Project, une organisation à but non lucratif dédiée à l’amélioration de la sécurité logicielle. Loin d’être un simple checklist de conformité, il sert de cadre pour les bonnes pratiques de développement et résume les incidents observés sur des applications réelles et lors d’évaluations de sécurité.

Pour les RSSI et responsables sécurité, le Top 10 est un outil stratégique : il met en évidence les points où les pratiques de développement et DevSecOps échouent le plus souvent, et aide à cibler les efforts pour obtenir la réduction de risque la plus efficace.

La Release Candidate (RC) 2025 reflète l’évolution du paysage des menaces tout en rappelant une vérité familière : en 2025 encore, la plupart des compromissions proviennent de faiblesses simples et évitables.

Ce guide propose une vue technique et concise de chaque catégorie, avec pour chaque vulnérabilité, un exemple, un POC et une recommandation.

A01:2025 – Broken Access Control

Pourquoi c’est important : L’accès non autorisé est toujours le risque numéro 1. Il crée un risque business immédiat : fuite de données clients, amendes réglementaires et perte de confiance lorsque des attaquants obtiennent des privilèges accrus et pivotent latéralement.

Exemple : Un utilisateur accédant aux données d’un autre tenant en modifiant un ID dans l’URL.

POC

GET /api/v1/users/1234  → réponse valide
GET /api/v1/users/1235  → si ceci retourne les données d’un autre utilisateur, le contrôle d’accès est cassé

Remédiation : Appliquez une autorisation côté serveur sur chaque requête : vérifiez la session, l’appartenance et les ACLs côté serveur, ne faites jamais confiance aux entrées client pour l’autorisation.

A02:2025 – Security Misconfiguration

Pourquoi c’est important : Tout composant, des services cloud aux frameworks, peut exposer la surface d’attaque si les configurations par défaut ne sont pas durcies. Ces erreurs simples sont des vecteurs d’entrée à fort impact, faciles à repérer pour un attaquant.

Exemple : Un bucket S3 de production laissé en lecture publique.

POC

# Lister un bucket S3 accessible publiquement
aws s3 ls s3://example-bucket --no-sign-request

Remédiation : Établissez une checklist de durcissement pour serveurs, conteneurs et services cloud. Désactivez les ports/usines non utilisés, appliquez le principe du moindre privilège et auditez continuellement les configurations via des scans automatisés et la validation IaC.

A03:2025 – Software Supply Chain Failures

Pourquoi c’est important : Des dépendances compromises ou des pipelines corrompus peuvent impacter simultanément de nombreuses applications.

Exemple : Un paquet ou composant compromis installé et utilisé par votre application.

POC

# Exemple : installer un paquet NPM vulnérable/compromis (lab only)
npm install vuln-package@1.0.0

Remédiation : Mettez en place un processus de gestion des correctifs qui suit les dépendances (y compris transitives). Supprimez les dépendances inutilisées, réduisez la surface, surveillez les CVE et adoptez SBOM/SCA et registres internes signés.

A04:2025 – Cryptographic Failures

Pourquoi c’est important : Un usage incorrect ou faible de primitives cryptographiques expose les données et permet l’usurpation d’identité.

Exemple : Stocker des mots de passe en SHA‑256 simple, sans sel, pepper ni fonction de dérivation adaptée.

POC

# Exporter les hashes et lancer un craquage hors‑ligne (lab only)
hashcat -m 1400 hashes.txt /path/rockyou.txt --show

Remédiation : Utilisez un hachage moderne et résistant en mémoire tel qu’Argon2id (avec sel) et envisagez l’usage d’un pepper géré hors‑base ; pour les données, employez des modes AEAD (AES‑GCM, ChaCha20‑Poly1305) et une gestion centralisée des clés (KMS/Vault).

A05:2025 – Injection

Pourquoi c’est important : Les injections permettent à un attaquant d’exécuter des commandes ou requêtes non prévues, conduisant souvent à la perte ou la compromission de données.

Exemple : Injection SQL dans un champ de recherche.

POC

Input: '; DROP TABLE users;--
Si l’application exécute cela et échoue ou que des données disparaissent, une injection est présente

Remédiation : Utilisez des requêtes paramétrées / statements préparés ou des API ORM sécurisées, validez et nettoyez les entrées et appliquez le principe du moindre privilège pour les comptes BD.

A06:2025 – Insecure Design

Pourquoi c’est important : Les défauts de conception ou d’architecture introduisent des faiblesses systémiques difficiles à corriger uniquement par des patches de code.

Exemple : Une API fait confiance à des champs contrôlés par le client (ex. is_admin dans le JSON ou l’en‑tête X-User-Role) et s’en sert pour décider d’autorisation, permettant une élévation de privilèges ou des actions business non autorisées.

POC

curl -sS -X POST http://localhost:3001/api/transfer \
  -H "Authorization: Bearer attacker" \
  -H "Content-Type: application/json" \
  -d '{"from":"alice","to":"bob","amount":1000,"is_admin":true}'

# Le serveur répond 200 OK et effectue l’action privilégiée parce qu’il a fait confiance au champ is_admin fourni par le client

Remédiation : Ne faites jamais confiance aux champs contrôlés par le client pour des décisions nécessitant autorité. Le serveur doit être source d’autorité pour rôles/permissions ; appliquez des patterns secure‑by‑design et intégrez des revues de sécurité dès la conception.

A07:2025 – Authentication Failures

Pourquoi c’est important : Une authentification faible permet l’usurpation d’identité et l’escalade de privilèges.

Exemple : Politique de mot de passe faible, tokens prédictibles ou réutilisation de jetons.

POC

Brute-force des mots de passe communs contre un point de connexion ou rejouer un token capturé pour accéder à un compte

Remédiation : Exigez MFA, appliquez une politique de mots de passe robuste, mettez en place du rate limiting, la rotation des tokens et une gestion sécurisée des sessions.

A08:2025 – Software or Data Integrity Failures

Pourquoi c’est important : Des binaires, paquets ou données altérés peuvent exécuter du code malveillant sans être détectés immédiatement.

Exemple : Un binaire ou une configuration modifiée déployée en production.

POC

Remplacer un binaire/config dans un environnement test et vérifier que l’application le charge/exécute

Remédiation : Signez les artefacts (checksums, signatures), vérifiez les signatures au déploiement/exécution, et protégez les dépôts d’artefacts ainsi que les clés de signature.

A09:2025 – Logging & Alerting Failures

Pourquoi c’est important : Sans détection et alerte, une compromission peut persister plus longtemps et s’aggraver.

Exemple : Des actions administratives critiques qui ne génèrent ni log ni alerte.

POC

Effectuer une action administrateur et rechercher dans les logs centralisés — si rien n’apparaît ou qu’aucune alerte n’est déclenchée, la détection échoue

Remédiation : Assurez une journalisation complète des événements de sécurité, orientez les logs vers un stockage résistant à la falsification, créez des alertes exploitables et testez régulièrement les processus de détection.

A10:2025 – Mishandling of Exceptional Conditions

Pourquoi c’est important : Une mauvaise gestion des erreurs peut divulguer des secrets ou laisser le système dans un état dangereux.

Exemple : Stack traces retournées aux utilisateurs ou comportement “fail‑open” en cas d’erreur.

POC

Soumettre une entrée malformée pour déclencher une exception ; vérifier la réponse pour des traces de pile ou données sensibles exposées

Remédiation : Gérez les erreurs proprement, échouez en sécurité (deny by default), nettoyez les messages d’erreur envoyés aux clients et consignez les détails complets uniquement dans des logs protégés.

Conclusion

L’OWASP Top 10 2025 rappelle une vérité simple : maîtrisez d’abord les bases. La plupart des compromissions ne proviennent pas d’exploits exotiques liés à l’IA générative, comme les attaques de type “LLM Injection”, mais d’erreurs courantes et faciles à corriger.

Les organisations doivent maîtriser les bases : contrôle d’accès solide, hygiène des configurations, gouvernance des dépendances et validation robuste des entrées.

Pour les RSSI, le message est clair : ces failles techniques se traduisent directement en risques business - fuite de données, interruption de service, atteinte à la réputation et non‑conformité réglementaire.

Chez Anantis, notre mission est de rapprocher exploitation et risque exécutif.

Nous identifions les faiblesses critiques, priorisons les corrections par impact business et délivrons des recommandations pertinentes et pragmatiques pour réduire rapidement et efficacement votre exposition.

➡️ Découvrir nos services de pentest · ➡️ Contactez‑nous