Principales vulnérabilités web 2026 : OWASP et CWE

Les principales vulnérabilités web à connaître en 2026 restent structurées autour du OWASP Top 10 Web (version 2021 stable, version 2025 en Release Candidate 1) et du CWE Top 25 MITRE (version 2025 publiée en décembre 2025 sur base de 39 080 CVE records analysées entre juin 2024 et juin 2025). Dix catégories OWASP : A01 Broken Access Control (la plus prévalente avec 3,81 % des applications testées et 318 000+ occurrences CWE associées), A02 Cryptographic Failures, A03 Injection (dont l'injection SQL, 62 445 CVE enregistrées), A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components (Log4Shell CVE-2021-44228, MOVEit CVE-2023-34362, xz-utils CVE-2024-3094), A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery. Côté CWE Top 25 2025, Cross-Site Scripting (CWE-79) reste #1, SQL injection (CWE-89) passe #2, Cross-Site Request Forgery (CWE-352) prend la #3. Cet article détaille le paysage 2026, décompose chaque famille majeure avec exploitation technique et défenses, fournit les CVE de référence, et cadre les priorités d'apprentissage pour un pentester junior. Le contenu présuppose un périmètre de test autorisé — tout essai décrit s'applique uniquement dans le cadre de Rules of Engagement signées (voir rapport de pentest).

1. Le paysage des vulnérabilités web en 2026

1.1 OWASP Top 10 Web 2021 vs 2025 RC1

Le OWASP Top 10 Web est mis à jour tous les 3-4 ans. La version 2021 est toujours la version stable en avril 2026 ; la version 2025 RC1 (Release Candidate 1) circule pour commentaires publics et devrait être publiée en version finale courant 2026. Les changements attendus entre 2021 et 2025 RC1 sont modestes : Broken Access Control reste #1, quelques catégories réordonnées, ajout d'une catégorie dédiée aux APIs qui rejoint la thématique OWASP API Security Top 10 2023.

1.2 CWE Top 25 2025

Classement complémentaire publié annuellement par MITRE en collaboration avec CISA. Score combiné sévérité × fréquence sur les CVE publiés l'année écoulée. 10 premières positions 2025 :

1.3 OWASP API Security Top 10 2023

Référentiel complémentaire critique en 2026 pour les applications modernes (SPA avec backends API, applications mobiles, intégrations B2B). Voir la ressource dédiée pentest greybox qui détaille les findings typiques API.

2. Broken Access Control (A01) et ses variantes

2.1 Définition et prévalence

Broken Access Control (BAC) désigne toute défaillance des contrôles d'autorisation qui permet à un utilisateur d'accéder à des ressources, fonctionnalités ou données hors de son périmètre autorisé. Catégorie #1 OWASP depuis 2021 avec 3,81 % des applications testées présentant au moins une occurrence et 318 000+ occurrences CWE associées — la plus prévalente sur le catalogue analysé.

Trois sous-familles principales :

2.2 Exemple d'exploitation IDOR

# exemple-idor-auth.py
# Exemple pedagogique : enumeration IDOR sur /api/v1/documents/{id}
# Prerequis : scope ecrit signe (Rules of Engagement), compte de test fourni.
# Usage hors scope = infraction art. 323-1 Code penal (STAD).
 
import requests
 
BASE = "https://app.example.test"
TOKEN_A = "<token_compte_test_A>"  # fourni par le commanditaire
 
headers = {"Authorization": f"Bearer {TOKEN_A}"}
 
# Reference legitime : User A lit son propre document
r = requests.get(f"{BASE}/api/v1/documents/101", headers=headers, timeout=5)
assert r.status_code == 200
 
# Test IDOR : User A tente de lire les documents d'autres users
accessible = []
for doc_id in range(1, 500):
    r = requests.get(f"{BASE}/api/v1/documents/{doc_id}", headers=headers, timeout=5)
    if r.status_code == 200:
        owner = r.json().get("owner_email", "unknown")
        if owner != "user_a@example.test":
            accessible.append((doc_id, owner))
 
print(f"IDOR confirme : {len(accessible)} documents d'autres users accessibles")
# Rapport : preuve d'exploitation a fournir avec listing anonymise,
# jamais avec les donnees reelles exfiltrees.

2.3 Défenses

• Authorization matrix documentée et testée côté serveur sur chaque endpoint.
• Object-level authorization systématique : vérifier que l'user authentifié possède/peut accéder à l'objet demandé, pas seulement qu'il est authentifié.
• Deny by default : refus explicite sauf allow-list.
• Rate limiting sur les endpoints listables pour ralentir l'énumération.
• Identifiants non-prédictibles (UUID v4 au lieu d'auto-increment) — mitigation, pas solution.

3. Injections : SQL, NoSQL, Command, LDAP, Code

3.1 SQL Injection (A03, CWE-89)

62 445 CVE enregistrées selon les données OWASP 2025, #2 CWE Top 25 2025. Quatre techniques principales :

CVE de référence : CVE-2023-29298 (Adobe ColdFusion, score CVSS 9.8), CVE-2024-27956 (WordPress plugin AutomaticWP, CVSS 9.9), CVE-2023-34478 (Apache Shiro, path traversal + injection). Outils d'exploitation : sqlmap (Bernardo Damele, référence depuis 2006), manipulation manuelle via Burp Repeater.

3.2 Command Injection (A03, CWE-78)

#9 CWE Top 25 2025. Pattern : input utilisateur concaténé dans une commande shell ou système. Typique dans les features ping tool, traceroute, import de fichier, génération PDF qui appellent wkhtmltopdf ou ffmpeg.

3.3 Code Injection (A03, CWE-94)

#7 CWE Top 25 2025. Exécution de code arbitraire serveur via eval() (PHP, Python, Node.js), désérialisation de données utilisateur, template injection (SSTI).

3.4 Cross-Site Scripting (CWE-79)

#1 CWE Top 25 2025 en fréquence de CVE. Trois variantes :

• Reflected XSS : payload dans l'URL ou formulaire, reflété dans la réponse. Nécessite interaction victime (phishing, lien piégé).
• Stored XSS : payload persisté en base (commentaire, profil, nom d'affichage) puis exécuté sur chaque chargement. Impact beaucoup plus large (tous les visiteurs de la page piégée).
• DOM-based XSS : exécution via manipulation du DOM côté client sans aller-retour serveur. Pattern courant dans les SPA modernes mal configurées.

Payload type pour détection initiale : <svg onload=alert(1)>, "><img src=x onerror=alert(1)>, ou payloads polyglottes.

4. Cryptographic Failures et Authentication (A02 + A07)

4.1 Cryptographic Failures

A02 OWASP, anciennement « Sensitive Data Exposure » avant 2021. CWE associés : CWE-259 (Use of Hard-coded Password), CWE-327 (Broken or Risky Crypto Algorithm), CWE-331 (Insufficient Entropy).

Exemples typiques pour un pentester :

• Mots de passe stockés en clair, MD5 ou SHA-1 nu (attendu : bcrypt, scrypt, Argon2id).
• TLS mal configuré : support SSLv3, TLS 1.0/1.1, cipher suites faibles (RC4, DES, NULL ciphers). Test via testssl.sh, sslyze.
• Absence de HSTS (HTTP Strict Transport Security) ou HSTS sans includeSubDomains.
• JWT signés avec algorithme HS256 et secret faible crackable par john/hashcat.
• Implémentations crypto custom mal conçues (ex: ECB mode, IV prédictible, absence d'authentification — AES-GCM au lieu de AES-CBC sans HMAC).
• Stockage de secrets dans le code source ou les logs.

4.2 Identification and Authentication Failures

A07 OWASP. Familles principales :

• Credential stuffing et absence de rate limiting sur login.
• Absence de MFA ou MFA faible (SMS, secret partagé sans FIDO2).
• Session fixation : l'attaquant fixe un session ID à la victime.
• Session token faible : prédictible, sans flags Secure/HttpOnly/SameSite.
• JWT flaws : algorithme none accepté, key confusion (RS256 → HS256 avec la public key comme secret), jku ou kid injection.
• OAuth 2.0 mal implémenté : absence de PKCE, redirect_uri trop permissif, state manquant → CSRF sur flow.
• Password reset faible : token prédictible, pas d'expiration, réutilisable.

5. Server-Side Request Forgery (SSRF) et Insecure Design

5.1 SSRF (A10, CWE-918)

Le serveur est manipulé pour effectuer une requête HTTP vers une URL choisie par l'attaquant. Impacts classiques :

• Accès aux metadata cloud : http://169.254.169.254/latest/meta-data/ sur AWS EC2 pour extraire les credentials IAM. Mitigation : IMDSv2 obligatoire (requête PUT préalable avec session token).
• Scan du réseau interne : http://localhost:port, http://10.0.0.0/8.
• Accès aux services internes non exposés (Redis, Elasticsearch, Kubernetes API, etcd).
• Bypass des ACL : le serveur vulnérable atteint des ressources que l'attaquant externe ne peut pas joindre.

CVE de référence : CVE-2021-26855 (Microsoft Exchange ProxyLogon, SSRF pré-auth + LPE = RCE), CVE-2021-21985 (VMware vCenter Server).

5.2 Insecure Design (A04)

Catégorie introduite en 2021 pour couvrir les défauts architecturaux impossibles à corriger par un patch. Exemples :

• Workflow permettant la génération massive sans rate limit adapté.
• Processus de reset password sans proof of ownership.
• Architecture qui confie la validation métier au client (front).
• Absence de threat modeling à la conception.
• Multi-tenancy mal conçue (isolation par label plutôt que par schéma/base).

La remédiation passe par une refonte architecturale, pas un patch. Les findings Insecure Design sont les plus coûteux à corriger (effort 20-100+ jours-homme typiquement).

6. Misconfiguration et composants vulnérables

6.1 Security Misconfiguration (A05)

CVE-2023-38646 Metabase RCE via misconfiguration H2 database. Patterns récurrents :

• Configuration par défaut laissée en production (admin/admin, pas de MFA).
• Debug mode activé (Django DEBUG=True, Symfony dev.env.local non renommé).
• En-têtes de sécurité manquants : X-Frame-Options, X-Content-Type-Options: nosniff, Referrer-Policy, CSP, HSTS.
• CORS trop permissif : Access-Control-Allow-Origin: * avec Access-Control-Allow-Credentials: true (invalide mais parfois accepté).
• Verbose error messages : stack traces exposées en prod (framework, version, path).
• Fichiers exposés : .git/, .env, composer.lock, backup.sql.zip, phpinfo.php.

6.2 Vulnerable and Outdated Components (A06)

L'une des catégories à plus fort impact en 2024-2025, documentée par des incidents majeurs :

Détection pentester : nuclei avec templates actualisés, extraction version via headers et fingerprints, scripts nmap -sV --script vuln, fuzz des endpoints /server-status, /actuator/*, /console.

Défense : SBOM (Software Bill of Materials) tenu à jour, scan SCA (Snyk, Dependency-Track, Dependabot, Renovate), politique de patching avec SLA (< 72h sur CVSS ≥ 9, < 30 jours sur ≥ 7).

7. Logging, Monitoring et Data Integrity

7.1 Software and Data Integrity Failures (A08)

Famille introduite en 2021, couvre les défauts de vérification d'intégrité :

• Désérialisation non sécurisée (CWE-502) : Java (ysoserial), Python pickle, PHP unserialize, .NET BinaryFormatter. RCE via gadget chains.
• CI/CD compromise : build compromis, dépendance trojanée (typosquatting npm/PyPI), credentials de déploiement exfiltrés.
• Mise à jour logicielle non signée : update fetché en HTTP sans signature.

CVE de référence : CVE-2022-22965 Spring4Shell (désérialisation), CVE-2023-42793 TeamCity (auth bypass CI).

7.2 Security Logging and Monitoring Failures (A09)

Moins glamour que les RCE mais critique pour la détection et la réponse à incident. Patterns testés en pentest :

• Absence de logs sur les événements critiques (login, failure, admin action, data export).
• Logs exposés publiquement (ex: /logs/application.log accessible sans auth).
• Logs contenant des secrets (mots de passe en POST loggés, tokens JWT complets, PII non redacted).
• Absence d'intégrité sur les logs (log tampering possible, pas de forwarding vers SIEM externe).
• Alerting absent ou trop permissif (10 000 alerts/jour = 0 alert).

8. Prévenir et remédier : approche SDLC

8.1 Shift-left vs defense-in-depth

La remédiation ne se limite pas aux correctifs post-pentest. Approche mature 2026 :

# sdlc-security-pipeline-reference.yml
# Integration securite dans le cycle de developpement, multi-couches.
 
design:
  - "Threat modeling STRIDE avant implementation (Microsoft Threat Modeling Tool, OWASP Threat Dragon)"
  - "Security requirements documentes (OWASP ASVS Level 2 minimum)"
  - "Architecture review avec checklist OWASP Proactive Controls v3"
 
development:
  - "Secure coding guidelines par langage (OWASP Cheat Sheet Series)"
  - "Framework avec defaults securises (Django, Rails, Spring Boot, Laravel)"
  - "Revue de code obligatoire avec focus securite sur changes sensibles"
  - "Pre-commit hooks : gitleaks (secrets), tfsec / checkov (IaC)"
 
ci_cd:
  sast: "Semgrep, CodeQL, SonarQube"
  sca: "Snyk, Dependency-Track, Dependabot, Renovate"
  dast: "OWASP ZAP baseline scan, Burp Suite Enterprise"
  container_scan: "Trivy, Grype"
  policy_check: "OPA Conftest, Kyverno"
  blocage_niveaux:
    - "HIGH ou CRITICAL block merge"
    - "MEDIUM require jira ticket pour remediation"
 
pre_production:
  - "Pentest greybox annuel sur apps critiques"
  - "Scan automatise hebdomadaire sur production"
  - "Bug bounty public ou prive selon maturite"
 
production:
  - "WAF avec OWASP CRS 4.0 (ModSecurity, Cloudflare, AWS WAF)"
  - "Runtime protection : RASP ou eBPF (Falco, Sysdig)"
  - "SIEM avec regles MITRE ATT&CK pour detection"
  - "IR playbooks par famille de vulnerabilite"

8.2 Programmes de formation

• OWASP ASVS (Application Security Verification Standard) v4.0.3 : checklist structurée en 3 niveaux de rigueur.
• OWASP Proactive Controls v3 : 10 contrôles clés côté développeur.
• NIST SSDF (Secure Software Development Framework) SP 800-218.
• ISO/IEC 27034 : sécurité applicative.

8.3 Outillage de pentest ciblé OWASP Top 10

Pour structurer ces outils dans une méthodologie complète, voir la ressource méthodologie pentest web qui détaille les phases PTES appliquées, et OWASP Testing Guide expliqué pour le référentiel WSTG v4.2.

9. Priorités d'apprentissage pour un pentester web junior

Ordre recommandé pour 6-12 mois d'auto-formation structurée :

1. SQL Injection (CWE-89) : PortSwigger Web Security Academy – SQL injection (gratuit), DVWA, SQLi Labs.
2. Cross-Site Scripting (CWE-79) : PortSwigger XSS, XSS Game (Google).
3. Broken Access Control / IDOR / BOLA : PortSwigger Access Control Vulnerabilities.
4. SSRF : PortSwigger SSRF, HackTheBox Endgame/Fortress.
5. Insecure Deserialization : PortSwigger Insecure Deserialization, ysoserial Java.
6. XXE (XML External Entity, CWE-611) : PortSwigger XXE.
7. Command Injection + Path Traversal (CWE-78, CWE-22) : PortSwigger dédiés.
8. SSTI (Server-Side Template Injection) : PortSwigger SSTI.
9. Race conditions : PortSwigger Race Conditions (2023).
10. GraphQL vulnerabilities (depth attacks, batching, introspection) : PortSwigger GraphQL, INE / HTB Academy.

Le parcours complet pour un pentester web est détaillé dans roadmap pentest web. Les étapes d'accès au métier sont documentées dans étapes pour devenir pentester.

Points clés à retenir

• OWASP Top 10 Web 2021 stable en 2026, version 2025 RC1 en draft : Broken Access Control reste #1.
• CWE Top 25 2025 : XSS #1, SQL Injection #2, CSRF #3, Path Traversal #5, Code Injection #7, Command Injection #9.
• 62 445 CVE d'injection SQL enregistrées selon OWASP 2025 — catégorie persistante malgré des décennies de connaissance.
• Broken Access Control = 3,81 % des apps testées, 318 000+ occurrences CWE, #1 prévalence.
• Composants vulnérables (A06) = CVE les plus coûteuses en impact : Log4Shell, MOVEit, xz-utils.
• Socle minimum pentester junior : SQLi, XSS, BAC/IDOR, SSRF, Insecure Deserialization — couvrent 70-80 % des findings.
• Défense = SDLC complet : threat modeling + SAST/SCA/DAST + pentest + WAF + SIEM, pas un seul outil.
• 70 % manuel / 30 % automatique sur un pentest web sérieux — les scanners seuls manquent les chaînes et la logique métier.