OWASP & failles applicatives — guide complet 2026

01 — OWASPComprendre l'écosystème

Voir notre fiche détaillée : OWASP — fiche complète.

Qu'est-ce que l'OWASP

L'OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif fondée en 2001, dédiée à l'amélioration de la sécurité des logiciels. Son modèle est ouvert et collaboratif : tous les contenus sont libres d'accès, produits par une communauté mondiale de milliers de bénévoles (développeurs, AppSec, chercheurs).

Productions principales

• OWASP Top 10 : classement des vulnérabilités web les plus critiques (le plus connu).
• OWASP API Security Top 10 : spécifique aux APIs (créé en 2019, mis à jour en 2023).
• OWASP Mobile Top 10 : pour applications mobiles.
• OWASP LLM Top 10 : pour applications utilisant des LLM (créé en 2023).
• ASVS (Application Security Verification Standard) : référentiel détaillé d'exigences de sécurité.
• Cheat Sheets : guides techniques par sujet.
• SAMM (Software Assurance Maturity Model) : modèle de maturité.
• ZAP (Zed Attack Proxy) : scanner web open source.
• Dependency-Check : outil SCA open source.

L'OWASP Top 10 version 2021

1. A01 — Broken Access Control : contrôles d'autorisation défaillants.
2. A02 — Cryptographic Failures : faiblesses cryptographiques.
3. A03 — Injection : SQL, XSS, OS command, LDAP, etc.
4. A04 — Insecure Design : défauts de conception.
5. A05 — Security Misconfiguration : configurations défaillantes.
6. A06 — Vulnerable and Outdated Components : bibliothèques non patchées.
7. A07 — Identification and Authentication Failures : failles d'authentification.
8. A08 — Software and Data Integrity Failures : défauts d'intégrité (supply chain).
9. A09 — Security Logging and Monitoring Failures : traces et supervision insuffisantes.
10. A10 — Server-Side Request Forgery (SSRF) : voir SSRF.

OWASP France et chapitres

L'OWASP a des chapitres locaux dans le monde entier. En France : chapitres à Paris, Lyon, Lille, Toulouse, Bordeaux, Nantes. Meetups réguliers, conférences (OWASP Global AppSec Europe annuel). Communauté active de développeurs et AppSec.

Pourquoi le Top 10 est si important

• Référence reconnue : utilisé partout (régulateurs, formations, outils).
• Mise à jour régulière : tous les 3-4 ans, basée sur des données réelles.
• Actionnable : chaque catégorie a des recommandations pratiques.
• Inclus dans les régulations : PCI DSS exige sa prise en compte, ISO 27001 le référence.
• Accessible : documentation libre, traductions, exemples.

02 — A01Broken Access Control

La faille la plus fréquente en 2024-2026. Affecte une majorité des applications testées. Voir notre fiche : IDOR.

Définition

Défaillance des contrôles d'autorisation : un utilisateur peut accéder à des ressources ou effectuer des actions qui ne lui sont pas destinées. Le système authentifie correctement l'utilisateur (qui il est) mais ne vérifie pas correctement ses autorisations (ce qu'il peut faire).

Variantes principales

• IDOR (Insecure Direct Object Reference) : modifier un identifiant dans l'URL ou la requête pour accéder aux données d'autres utilisateurs (ex. /api/users/123 → /api/users/124).
• Élévation de privilèges horizontale : accéder aux données d'autres utilisateurs de même niveau.
• Élévation de privilèges verticale : passer de utilisateur à admin.
• Path traversal : accéder à des fichiers en dehors du répertoire prévu.
• Forced browsing : accéder à des URLs non listées mais devinées.
• Bypass de contrôles : désactiver les vérifications côté client.
• JWT manipulation : modifier les claims d'un token mal signé.
• Mass assignment : ajouter des champs sensibles dans une requête (ex. isAdmin: true).

Exemples concrets

• Facture utilisateur : /invoices/4521.pdf accessible en changeant l'identifiant.
• Suppression API : DELETE /api/orders/123 sans vérifier que c'est la commande de l'utilisateur connecté.
• Console admin : /admin accessible directement sans contrôle de rôle.
• GraphQL : requête sur les données d'un autre utilisateur sans contrôle.

Prévention

• Vérification systématique côté serveur à chaque accès à une ressource.
• Modèle d'autorisation centralisé (RBAC, ABAC, ACL).
• Refuser par défaut, autoriser explicitement.
• Tests automatisés sur les contrôles d'accès.
• Tokens sécurisés (JWT signés correctement, sessions invalidables).
• Logs des accès refusés.
• Frameworks d'autorisation modernes (Spring Security, Casbin, OPA, AuthZed).

03 — A02Cryptographic Failures

Catégories

• Données sensibles non chiffrées : en transit (HTTP au lieu d'HTTPS) ou au repos (BDD non chiffrée).
• Algorithmes obsolètes : MD5, SHA-1 pour hashing, DES, RC4, TLS 1.0/1.1.
• Clés faibles : RSA 1024, ECDSA < 256 bits, clés AES insuffisantes.
• Certificats invalides : auto-signés en prod, expirés, mauvais nom commun.
• Secrets exposés : clés API, mots de passe en clair dans le code, dans les logs, dans des dépôts publics GitHub.
• Hashes inadéquats : mots de passe hashés avec MD5/SHA-1 au lieu d'Argon2, bcrypt, scrypt, PBKDF2.
• Génération aléatoire faible : PRNG non cryptographique pour secrets/tokens.
• Implémentations cryptographiques personnalisées : à éviter, utiliser des bibliothèques éprouvées.

Bonnes pratiques 2026

• HTTPS partout, redirections automatiques, HSTS.
• TLS 1.3 ou minimum 1.2, suites de chiffrement modernes uniquement.
• Hashing passwords : Argon2id (recommandé), bcrypt minimum.
• Chiffrement symétrique : AES-256-GCM.
• Asymétrique : RSA-3072+, Ed25519, X25519, ECDSA P-256+.
• Migration post-quantique à anticiper : ML-KEM, ML-DSA (NIST 2024).
• Gestion des secrets : KMS, HSM, gestionnaires (HashiCorp Vault, AWS Secrets Manager, Doppler).
• Aucun secret dans le code : scan des dépôts (TruffleHog, gitleaks).
• Rotation régulière des clés et secrets.

Outils de vérification

• SSL Labs : test public de configuration TLS.
• testssl.sh : équivalent en CLI.
• Mozilla Observatory : scan headers HTTP de sécurité.
• Hardenize : audit complet domaine + email.

04 — A03Injection (SQL, XSS, etc.)

Catégorie historique mais toujours d'actualité. Inclut plusieurs sous-types.

Injection SQL

Voir notre fiche : Injection SQL.

• Insertion de code SQL malveillant via des entrées utilisateur.
• Permet : lecture/modification/suppression de données, contournement d'authentification, exécution de commandes système (selon SGBD).
• Toujours présent en 2026, surtout dans le code legacy.
• Prévention : requêtes paramétrées (prepared statements), ORM bien utilisé, validation des entrées, principe du moindre privilège pour la BDD, WAF en complément.

Cross-Site Scripting (XSS)

Voir notre fiche : XSS.

• Injection de scripts JavaScript dans une page web vue par d'autres utilisateurs.
• Trois variantes : réfléchi (URL malveillante), stocké (BDD), DOM-based (manipulation côté client).
• Permet : vol de cookies/tokens, défacement, redirection, keylogger, actions au nom de l'utilisateur.
• Prévention : échappement contextuel à l'affichage, Content Security Policy (CSP), validation des entrées, HttpOnly sur cookies sensibles, frameworks modernes (qui échappent par défaut).

Autres injections

• OS Command Injection : exécution de commandes système (impact maximal).
• LDAP Injection : dans les requêtes d'annuaire.
• XPath Injection : dans les requêtes XML.
• NoSQL Injection : MongoDB, Redis, etc. (logique différente du SQL classique).
• Template Injection (SSTI) : dans les moteurs de templates (Jinja, Twig, Handlebars), peut mener à RCE.
• Header Injection : CRLF injection dans les headers HTTP.
• Email Header Injection : insertion dans les en-têtes d'emails envoyés.
• Prompt Injection : spécifique aux LLM (voir section dédiée).

Principe général de prévention

Ne jamais concaténer des entrées non fiables dans des chaînes destinées à être interprétées (SQL, HTML, OS, template, etc.). Utiliser des mécanismes d'encodage/échappement ou de paramétrage adaptés au contexte de destination. Validation stricte en entrée + encodage stricte en sortie : défense en profondeur.

05 — A04-A05Design & Configuration

A04 — Insecure Design

Catégorie ajoutée en 2021. Concerne les défauts architecturaux qui ne sont pas réductibles à des bugs d'implémentation.

• Manque de modélisation des menaces dès la conception.
• Absence de contrôles essentiels par design (rate limiting, validation, logging).
• Logiques métier exploitables (parcours d'achat sans vérification, race conditions).
• Architectures qui ne permettent pas la défense en profondeur.
• Pas de séparation des privilèges.

Prévention : threat modeling (STRIDE, PASTA), revue de design en amont, abuse cases, principe du moindre privilège, séparation des responsabilités, secure development lifecycle (SDLC).

A05 — Security Misconfiguration

• Configurations par défaut non durcies : credentials par défaut, services activés inutiles, ports ouverts.
• Headers HTTP de sécurité manquants : HSTS, CSP, X-Frame-Options, X-Content-Type-Options.
• Messages d'erreur exposant des détails internes (stacktraces, versions, chemins).
• Listing de répertoires activé.
• Comptes par défaut non supprimés.
• CORS trop permissif.
• Stockage cloud (S3, Azure Blob) public par erreur.
• Containers/images non patchés.
• Permissions IAM excessives sur le cloud.

Prévention : hardening systématique, infrastructure as code (IaC) avec scans (Checkov, tfsec), CSPM (Cloud Security Posture Management), revues régulières de configuration, tests automatisés (DAST, scans réseau).

06 — A06-A08Composants & intégrité

A06 — Vulnerable and Outdated Components

Une application moderne contient des centaines à milliers de bibliothèques tierces (npm, Maven, PyPI, NuGet, etc.). Une seule vulnérable et c'est l'application qui devient vulnérable.

• Cas marquants : Log4Shell (Log4j 2021), Spring4Shell (2022), OpenSSL Heartbleed (2014), XZ Utils backdoor (2024), polyfill.io (2024).
• Bibliothèques abandonnées sans correctifs.
• Dépendances transitives invisibles.
• Versions épinglées trop longtemps sans mise à jour.

Prévention :

• Software Composition Analysis (SCA) : Snyk, Dependabot, OWASP Dependency-Check, Trivy, Mend.
• SBOM (Software Bill of Materials) : inventaire des composants, exigé par CRA et secteurs critiques.
• Mises à jour régulières et automatisées.
• Surveillance des CVE (CVE/CVSS/EPSS).
• Politique de durée de vie des dépendances.
• Préférer les bibliothèques activement maintenues.

A08 — Software and Data Integrity Failures

Catégorie liée aux attaques de la supply chain.

• Mises à jour automatiques sans vérification d'intégrité (signatures).
• Pipelines CI/CD vulnérables.
• Désérialisation non sécurisée d'objets fournis par l'utilisateur.
• Inclusion de scripts depuis des CDN tiers non vérifiés (cas polyfill.io).

Prévention :

• Signatures cryptographiques des artefacts (Sigstore, cosign).
• SBOM et provenance attestation.
• Sécurité des pipelines CI/CD (SLSA framework).
• Subresource Integrity (SRI) pour scripts CDN.
• Revues de code obligatoires avant déploiement.
• Désérialisation sécurisée (whitelist de types, formats sûrs comme JSON).

07 — A07Failles d'authentification

Voir : IAM, MFA, Passkey, Credential stuffing.

Catégories de failles

• Mots de passe faibles : pas de politique stricte, dictionnaire facile.
• Stockage en clair ou hashé faiblement (MD5, SHA-1).
• Pas de MFA ou MFA mal implémenté (bypass possible).
• Sessions vulnérables : tokens prédictibles, pas d'expiration, pas d'invalidation côté serveur.
• Reset password vulnérable : questions secrètes faibles, tokens prédictibles, énumération d'emails.
• Credential stuffing non protégé : pas de rate limiting, pas de détection d'anomalies.
• Brute force : pas de blocage après échecs.
• Énumération d'utilisateurs : messages d'erreur différents pour user existant vs inexistant.
• JWT mal géré : signature non vérifiée, algorithme none accepté, pas d'expiration.
• Auth Bypass : contournement par paramètres oubliés, race conditions.

Bonnes pratiques modernes

• Passkeys et FIDO2 : à privilégier.
• MFA par authenticator (pas SMS) sur tout compte sensible.
• Hashing : Argon2id ou bcrypt (cost factor 12+).
• Politique de mots de passe : longueur minimale, vérification contre dictionnaires (haveibeenpwned API).
• Rate limiting et détection d'anomalies (login failures, geo, device).
• Sessions courtes, refresh tokens, possibilité de déconnexion globale.
• JWT correctement signés (RS256, ES256), validation systématique de l'algorithme.
• Reset password : tokens longs aléatoires, expiration courte, usage unique.
• SSO centralisé pour réduire la surface d'attaque.
• Logs des événements d'authentification.

08 — A10SSRF et autres failles serveur

SSRF (Server-Side Request Forgery)

Voir notre fiche : SSRF.

• L'attaquant force le serveur à effectuer des requêtes HTTP vers des URLs choisies.
• Permet : accès à des ressources internes (métadonnées cloud, services internes), exfiltration de données, scan réseau interne, exploitation de vulnérabilités internes via le serveur.
• Particulièrement dangereux dans le cloud : accès aux metadata services (AWS IMDS, GCP, Azure) → vol de credentials cloud.
• Cas Capital One (2019) : SSRF + IAM mal configuré = vol de 100 millions de comptes.
• Prévention : liste blanche d'URLs autorisées, pas de redirection suivie automatiquement, segmentation réseau, IMDSv2 obligatoire en AWS.

CSRF (Cross-Site Request Forgery)

Voir notre fiche : CSRF.

• L'attaquant force la victime authentifiée à effectuer une action sur un site (transfert d'argent, changement de mot de passe).
• Moins critique en 2026 grâce aux protections par défaut des frameworks modernes.
• Prévention : tokens CSRF (anti-CSRF), attribut SameSite=Lax/Strict sur cookies, vérification de l'origine, double soumission de cookie, frameworks modernes (Django, Rails, Spring le font par défaut).

XXE (XML External Entity)

• Injection d'entités externes dans des documents XML.
• Permet : lecture de fichiers serveur, SSRF, déni de service.
• Prévention : désactiver le traitement des entités externes (par défaut dans la plupart des bibliothèques modernes).

Race conditions

• Exploitation de fenêtres temporelles entre vérification et action (TOCTOU).
• Cas typiques : double dépense, double utilisation de coupon, contournement de limites.
• Prévention : locks atomiques, transactions BDD, idempotence, contrôles côté serveur uniquement.

09 — SpécialisésAPI Security & LLM Top 10

OWASP API Security Top 10 (2023)

Voir notre fiche : API security.

Les APIs ont des problématiques spécifiques par rapport aux applications web traditionnelles.

• API1 — Broken Object Level Authorization (BOLA) : l'IDOR appliqué aux APIs, faille la plus fréquente.
• API2 — Broken Authentication : tokens, JWT, OAuth.
• API3 — Broken Object Property Level Authorization : exposition ou modification non autorisée de propriétés.
• API4 — Unrestricted Resource Consumption : déni de service par absence de rate limiting.
• API5 — Broken Function Level Authorization : élévation de privilèges horizontale ou verticale.
• API6 — Unrestricted Access to Sensitive Business Flows : abus de logique métier (achat en gros, scraping massif).
• API7 — Server Side Request Forgery : SSRF dans les APIs.
• API8 — Security Misconfiguration : CORS, headers, debug.
• API9 — Improper Inventory Management : APIs zombies, versions obsolètes oubliées.
• API10 — Unsafe Consumption of APIs : faire confiance aveuglément aux APIs tierces consommées.

OWASP LLM Top 10 (2023)

Voir notre fiche : Prompt injection.

Catégorie ajoutée en 2023 spécifiquement pour les applications utilisant des LLM (ChatGPT, Claude, Gemini, etc. intégrés dans des produits).

• LLM01 — Prompt Injection : contournement des instructions système par injection dans le prompt utilisateur.
• LLM02 — Insecure Output Handling : traiter la sortie du LLM comme du code/HTML/SQL fiable (XSS, injection).
• LLM03 — Training Data Poisoning : empoisonnement des données d'entraînement.
• LLM04 — Model Denial of Service : requêtes coûteuses qui saturent.
• LLM05 — Supply Chain Vulnerabilities : modèles tiers, datasets, fine-tuning compromis.
• LLM06 — Sensitive Information Disclosure : fuite de données via le LLM.
• LLM07 — Insecure Plugin Design : plugins/tools mal sécurisés.
• LLM08 — Excessive Agency : trop de pouvoirs accordés à un agent autonome.
• LLM09 — Overreliance : confiance aveugle dans les outputs.
• LLM10 — Model Theft : extraction du modèle ou de ses paramètres.

OWASP Mobile Top 10 (2024)

• M1 — Improper Credential Usage.
• M2 — Inadequate Supply Chain Security.
• M3 — Insecure Authentication/Authorization.
• M4 — Insufficient Input/Output Validation.
• M5 — Insecure Communication.
• M6 — Inadequate Privacy Controls.
• M7 — Insufficient Binary Protections.
• M8 — Security Misconfiguration.
• M9 — Insecure Data Storage.
• M10 — Insufficient Cryptography.

10 — PréventionApproche DevSecOps

Voir : DevSecOps.

Le shift left

Le coût de correction d'une vulnérabilité augmente exponentiellement entre les phases du développement :

• Pendant le design : ~1×
• Pendant le développement : ~5×
• Pendant les tests : ~10×
• En production : ~30-100×
• Après incident exploité : ~1000×+ (gestion crise, communication, juridique)

D'où l'intérêt du shift left : intégrer la sécurité au plus tôt dans le cycle.

Pratiques essentielles

1. Formation Secure Coding : tous les développeurs formés aux fondamentaux (OWASP, langage spécifique).
2. Modélisation des menaces (threat modeling) en phase de design : STRIDE, PASTA.
3. Code review systématique avec checkpoint sécurité.
4. SAST (Static Application Security Testing) : SonarQube, Semgrep, Snyk Code, GitHub Advanced Security, Checkmarx.
5. SCA (Software Composition Analysis) : Snyk, Dependabot, Renovate, OWASP Dependency-Check, Trivy.
6. DAST (Dynamic Application Security Testing) : OWASP ZAP, Burp Suite, Acunetix, Detectify.
7. IAST (Interactive Application Security Testing) : instrumentation runtime.
8. Container scanning : Trivy, Snyk Container, Clair.
9. IaC scanning : Checkov, tfsec, Terrascan.
10. Secret scanning : TruffleHog, gitleaks, GitHub secret scanning.
11. Pentests annuels par tiers indépendants.
12. Bug bounty pour applications publiques exposées (voir section suivante).
13. Defense in depth : WAF, RASP, observabilité, monitoring.

Intégration CI/CD

• SAST + SCA + secret scanning à chaque pull request.
• Bloquer le merge si vulnérabilités critiques.
• DAST sur environnements de pré-production.
• Container scanning au build et au déploiement.
• Tests de sécurité automatisés dans la suite de tests.

Métriques de sécurité applicative

• Nombre de vulnérabilités par criticité.
• Temps moyen de correction (MTTR).
• Densité de vulnérabilités (par 1000 lignes de code).
• Taux de couverture des tests sécurité.
• Pourcentage de dépendances à jour.
• Score OWASP ASVS atteint.

11 — Bug bountyTests offensifs externes

Voir : Bug bounty et Pentester.

Bug bounty vs pentest

Plateformes principales

• HackerOne : leader mondial, basée aux US.
• Bugcrowd : deuxième acteur mondial.
• Intigriti : acteur européen (Belgique).
• YesWeHack : acteur français de référence, choisi par administrations FR.
• Synack : modèle hybride avec testeurs vérifiés.

Grille de récompenses typique

• XSS basique : 100-500 €
• IDOR avec impact : 500-2 000 €
• Injection SQL : 2 000-10 000 €
• Authentication bypass : 5 000-20 000 €
• SSRF avec impact cloud : 5 000-30 000 €
• RCE (Remote Code Execution) : 10 000-100 000 €+
• Vulnérabilités critiques sur infrastructure : 100 000 €+ (rares)

Mise en place d'un programme

1. Définir le périmètre (quelles applications, quels types).
2. Définir les exclusions (DDoS, social engineering, physical).
3. Établir la grille de récompenses.
4. Préparer l'équipe interne pour traiter les rapports.
5. Démarrer en privé (invitations) avant public.
6. Coordination avec divulgation responsable (CVD).
7. Métriques : temps moyen de réponse, validation, correction.

Cadre légal

Le bug bounty est légal et structuré : les chercheurs opèrent dans un cadre défini par l'entreprise. C'est fondamentalement différent du hacking malveillant (sanctionné par les articles 323-1 et suivants du Code pénal). Sans programme bug bounty, tester une application sans autorisation est illégal.

Pour les acteurs critiques

Pour banques, défense, OIV, le bug bounty est souvent complété par :

• Pentests qualifiés PASSI de l'ANSSI.
• Red Team exercises (simulations d'attaques complètes).
• TLPT pour DORA (Threat-Led Penetration Testing).
• Audits de sécurité réglementaires.