Vulnérabilités & Exploitation Web
En s'appuyant sur le référentiel OWASP Top 10:2025 (dernière édition, publiée en janvier 2026) : chaque catégorie de risque, ses techniques de test, et les outils de référence pour les mettre en pratique.
1. OWASP Top 10:2025
Les 10 catégories de risques les plus critiques, à jour de la dernière édition.
2. Injection & Contrôle d'Accès
SQLi, XSS, IDOR — les familles de failles les plus fréquemment rencontrées.
3. Outils & Méthodologie
Burp Suite, SQLMap, fuzzing de répertoires, et une démarche de test complète.
Concepts
- L'OWASP (Open Worldwide Application Security Project) publie périodiquement un classement des 10 risques applicatifs les plus critiques, basé sur l'analyse de centaines de milliers de vulnérabilités réelles.
- Ce n'est pas une classification technique stricte, mais un outil de priorisation : il aide à orienter l'effort de test là où l'impact réel est le plus probable.
- Dernière édition : 2025 (publiée en janvier 2026), qui succède à l'édition 2021 avec deux nouvelles catégories.
Les 10 Catégories 2025
A01Broken Access Control
A02Security Misconfiguration
A03Software Supply Chain Failures
A04Cryptographic Failures
A05Injection
A06Insecure Design
A07Authentication Failures
A08Software or Data Integrity Failures
A09Security Logging & Alerting Failures
A10Mishandling of Exceptional Conditions
Concepts
- Risque n°1 du classement 2025 : un utilisateur accède à des ressources ou actions qui ne devraient pas lui être accessibles.
- Depuis 2025, la SSRF (Server-Side Request Forgery) est intégrée dans cette catégorie plutôt que traitée séparément.
Ce qu'il Faut Tester
- IDOR : modifier un identifiant dans l'URL (
/api/users/101) pour accéder aux données d'un autre compte.
- Contournement de rôle : accéder à une page admin avec un compte utilisateur standard.
- CORS mal configuré : vérifier si l'en-tête
Access-Control-Allow-Origin autorise n'importe quelle origine.
- SSRF : tester si un paramètre d'URL fourni par l'utilisateur peut forcer le serveur à effectuer une requête vers une ressource interne.
Concepts
- Deuxième risque du classement 2025 (contre 5e place en 2021) — les erreurs de configuration se multiplient avec la complexité croissante des architectures cloud/microservices.
- Inclut : comptes/mots de passe par défaut, services inutiles activés, messages d'erreur trop verbeux, en-têtes de sécurité manquants.
Démo — Vérifier les En-têtes de Sécurité
curl -I -v https://cible.exemple
# En-têtes à surveiller :
# Content-Security-Policy, X-Frame-Options,
# Strict-Transport-Security, X-Content-Type-Options
Concepts
- Anciennement nommée "Sensitive Data Exposure" — recentrée depuis 2021 sur la cause racine plutôt que le symptôme.
- À vérifier : usage d'HTTP au lieu d'HTTPS, algorithmes de chiffrement obsolètes, clés de chiffrement faibles ou codées en dur, données sensibles stockées sans chiffrement.
- Souvent détectable simplement en observant si le formulaire de connexion est servi en clair, ou si un certificat TLS est expiré/auto-signé en production.
Concepts
- Une entrée utilisateur non validée est concaténée directement dans une requête SQL, permettant d'en altérer la logique.
- Reste l'une des vulnérabilités à plus fort impact du classement, malgré une fréquence plus faible que le XSS.
Démo Condensée
# Test manuel basique dans un champ de connexion
Champ mot de passe : ' OR '1'='1
# Détection et exploitation automatisée
sqlmap -u "https://cible.exemple/item?id=1" --batch --dbs
Concepts
- Injection de script exécuté dans le navigateur d'une victime, désormais regroupée sous la catégorie Injection.
- Reflected : renvoyé immédiatement dans la réponse. Stored : persiste côté serveur (ex: commentaire). DOM-based : exécuté entièrement côté client, sans passer par le serveur.
Payload de Test Classique
<script>alert(document.domain)</script>
# Variante pour contourner un filtre basique
<img src=x onerror=alert(1)>
Concepts
- Contrairement aux autres catégories, ce risque ne vient pas d'une erreur d'implémentation mais d'une faille dans l'architecture ou la logique métier elle-même.
- Exemple typique : une fonctionnalité de réinitialisation de mot de passe sans limitation du nombre de tentatives, rendant un brute-force du code de vérification possible même si le code est bien implémenté.
- Se corrige par la modélisation de menaces (threat modeling) en amont du développement, pas par un simple correctif.
Concepts
- Anciennement "Identification and Authentication Failures" — recentré sur les mécanismes d'authentification eux-mêmes.
- Inclut : absence de verrouillage de compte, mots de passe faibles acceptés, gestion de session prévisible ou non renouvelée après connexion.
Démo Condensée
# Brute-force d'un formulaire de connexion web
hydra -l admin -P wordlist.txt cible.exemple http-post-form \
"/login:user=^USER^&pass=^PASS^:Identifiants invalides"
Une Catégorie Élargie en 2025
- Étend l'ancienne catégorie "Vulnerable and Outdated Components" à l'ensemble de la chaîne logicielle : dépendances tierces, systèmes de build, infrastructure de distribution.
- Votée comme priorité majeure par la communauté malgré une faible présence dans les données de test — les outils pour la détecter systématiquement sont encore en maturation.
- À vérifier : versions de bibliothèques utilisées par l'application, présence de CVE connues sur ces dépendances, intégrité des pipelines CI/CD si le périmètre le permet.
Concepts
- Se concentre sur le défaut de vérification de l'intégrité du code et des données, à un niveau plus local que les failles de chaîne logicielle (A03).
- Exemples : mise à jour applicative installée sans vérification de signature, désérialisation de données non fiables pouvant mener à une exécution de code.
Concepts
- Une bonne journalisation sans mécanisme d'alerte associé a une valeur limitée pour détecter un incident en cours — d'où le changement de nom en 2025 pour insister sur l'alerting.
- À évaluer en pentest : les tentatives de connexion échouées, injections ou scans sont-elles journalisées ? Génèrent-elles une alerte exploitable par une équipe de sécurité ?
- Catégorie difficile à mesurer automatiquement — intégrée principalement via le vote de la communauté, pas uniquement les données de test.
Nouvelle Catégorie 2025
- Couvre la mauvaise gestion des erreurs, la logique défaillante face à des conditions anormales, et les comportements de type "fail-open" (le système autorise l'accès par défaut en cas d'erreur, au lieu de le refuser).
- À tester : que se passe-t-il si un service externe dont dépend l'authentification tombe en panne ? L'application se ferme-t-elle de façon sécurisée (fail-closed), ou laisse-t-elle passer par défaut ?
Concepts
- Complète le crawling/spidering du chapitre 12 : au lieu de suivre les liens visibles, on teste directement l'existence de chemins non liés à partir d'une liste de mots (wordlist).
- Permet de découvrir des panneaux d'administration, des sauvegardes ou des fichiers de configuration oubliés.
Démo
# Fuzzing de répertoires avec ffuf
ffuf -w wordlist.txt -u https://cible.exemple/FUZZ
# Alternative avec gobuster
gobuster dir -u https://cible.exemple -w wordlist.txt
Concepts
- Proxy d'interception qui se positionne entre le navigateur et le serveur : chaque requête peut être observée, mise en pause et modifiée avant envoi.
- L'outil central de la quasi-totalité des tests d'intrusion web manuels.
Modules Clés
- Proxy : interception et historique de toutes les requêtes/réponses.
- Repeater : renvoyer et modifier une requête spécifique à volonté.
- Intruder : automatiser l'envoi de multiples variantes d'une requête (brute-force, fuzzing de paramètres).
- Decoder : encoder/décoder rapidement (Base64, URL, Hex...).
Démo Condensée
# Détecter une injection sur un paramètre GET
sqlmap -u "https://cible.exemple/item?id=1" --batch
# Lister les bases de données accessibles
sqlmap -u "https://cible.exemple/item?id=1" --batch --dbs
# Lister les tables d'une base précise
sqlmap -u "https://cible.exemple/item?id=1" --batch -D nom_base --tables
# Extraire le contenu d'une table
sqlmap -u "https://cible.exemple/item?id=1" --batch -D nom_base -T utilisateurs --dump
Démarche Type
- 1. Cartographie : crawling passif (Burp) et spidering actif (ZAP), déjà vus au chapitre 12.
- 2. Découverte de contenu caché : fuzzing de répertoires et fichiers (ffuf/gobuster).
- 3. Test systématique par catégorie OWASP : contrôle d'accès, injection, authentification, configuration — dans cet ordre de priorité, en fonction de l'impact potentiel.
- 4. Exploitation contrôlée : valider techniquement chaque faille suspectée (SQLMap, payloads XSS, manipulation de requêtes via Repeater).
- 5. Documentation : chaque preuve doit être reproductible et associée à une catégorie OWASP précise dans le rapport final.
Idée centrale : un web pentest ne consiste pas à lancer quelques scanners. Il faut comprendre le comportement attendu de l'application, identifier les frontières de confiance, puis vérifier si ces frontières peuvent être contournées.
1. Reconnaître
Technologies, routes, rôles, paramètres, fonctionnalités.
→
2. Comprendre
Flux normaux, logique métier et contrôles de sécurité.
→
3. Tester
Modifier une variable à la fois et observer la différence.
→
4. Valider
Reproduire, mesurer l'impact et documenter la preuve.
Surface
Pages, API, fichiers, paramètres, cookies, headers, endpoints et interfaces d'administration.
Confiance
Ne jamais supposer qu'une valeur envoyée par le navigateur est fiable.
Preuve
Une anomalie devient une finding lorsqu'elle est reproductible et contextualisée.
Question 1 — Qui ?
- Utilisateur anonyme ?
- Utilisateur authentifié ?
- Utilisateur privilégié / administrateur ?
Question 2 — Quoi ?
- Quelle ressource est demandée ?
- Quelle action est effectuée ?
- Quelles données devraient être visibles ou modifiables ?
Règle pratique : capturer d'abord une requête légitime et comprendre son rôle. Ensuite seulement, modifier une donnée précise pour vérifier si le serveur applique réellement le contrôle attendu.
Endpoints
/login, /admin, /api/..., upload, recherche, export, reset password.
Entrées
Query string, body, path parameters, cookies, headers, JSON, multipart.
États
Non authentifié, utilisateur, manager, admin, compte verrouillé, session expirée.
# Reconnaissance légère
curl -I https://cible.exemple
whatweb https://cible.exemple
nmap -sV -p 80,443 cible.exemple
Le résultat recherché n'est pas seulement une liste de technologies : c'est une carte permettant de relier fonctionnalité → endpoint → paramètre → rôle → impact potentiel.
Indices côté serveur
- Headers
Server, Via, X-Powered-By. - Pages d'erreur et conventions de framework.
- Cookies et attributs de session.
- Formats des URLs et réponses API.
Indices côté client
- Commentaires HTML et fichiers JavaScript.
- Bundles et noms de bibliothèques.
- Routes révélées dans le code client.
- Source maps lorsqu'elles sont exposées.
Attention : un fingerprint est un indice, pas une preuve absolue de version. Confirmer par plusieurs observations avant de conclure.
Authentification — « Qui es-tu ? »
- Login / mot de passe
- MFA
- Tokens / sessions
- Reset password
Autorisation — « Que peux-tu faire ? »
- Rôles
- Permissions
- Accès à une ressource précise
- Actions privilégiées
→
AuthZContrôle du rôle et de la ressource
→
ActionOpération autorisée
Le test d'accès doit comparer plusieurs identités sur la même fonctionnalité. L'objectif est de vérifier que le serveur décide lui-même si l'action est autorisée.
Horizontal
Utilisateur A tente d'accéder à la ressource de l'utilisateur B.
GET /api/users/102/profile
Vertical
Utilisateur standard tente une fonction réservée à un rôle supérieur.
GET /admin/users
POST /admin/users/disable
Preuve forte : conserver la requête originale, la requête modifiée, l'identité utilisée et la différence de réponse.
Points à rechercher
- ID numérique séquentiel
- UUID ou identifiant dans JSON
- Nom de fichier / document
- ID dans URL, body ou header
Approche
# Requête légitime
GET /api/invoices/1001
# Puis modifier uniquement l'identifiant
GET /api/invoices/1002
Comparer code HTTP, taille, champs JSON et données retournées.
Exposition
Interfaces d'administration, debug, fichiers de sauvegarde, répertoires listables.
Headers
CSP, HSTS, X-Content-Type-Options, X-Frame-Options et politiques CORS.
Erreurs
Stack traces, chemins locaux, versions, SQL errors, exceptions détaillées.
curl -I https://cible.exemple
curl -s https://cible.exemple/nonexistent-page
Une mauvaise configuration n'est pas seulement « un header absent » : évaluer si l'exposition crée réellement une capacité supplémentaire pour un attaquant.
Client
- Bibliothèques JavaScript tierces
- Versions exposées dans les bundles
- CDN externes
- Source maps
Serveur / CI-CD
- Dépendances applicatives
- Images de conteneurs
- Packages et artefacts
- Pipeline de build si explicitement dans le périmètre
Principe : identifier d'abord le composant et sa version, puis vérifier si la version observée est réellement affectée par une vulnérabilité connue.
Transport
- HTTP vers HTTPS
- Certificat valide
- Configuration TLS
- Redirection et HSTS
Données
- Secrets dans les réponses
- Tokens exposés
- Données sensibles dans URL
- Secrets codés en dur dans JS
curl -I http://cible.exemple
curl -I https://cible.exemple
Avant d'utiliser un outil automatisé, identifier où la donnée contrôlée par l'utilisateur atteint un interpréteur : SQL, HTML, JavaScript, commande système, template, LDAP, etc.
Source
Paramètre, cookie, header, JSON, upload.
Sink
Requête SQL, HTML, JS, shell, template ou autre interpréteur.
Validation
Observer une différence contrôlée et reproductible.
Ne pas confondre réflexion d'une entrée et exécution d'un payload. Le contexte de sortie détermine le test à effectuer.
1. Identifier
Paramètre potentiellement dynamique
→
2. Comparer
Entrées normales et modifiées
→
3. Confirmer
Comportement reproductible
→
4. Automatiser
SQLMap avec périmètre contrôlé
sqlmap -u "https://cible.exemple/item?id=1" --batch
sqlmap -u "https://cible.exemple/item?id=1" --batch --dbs
L'automatisation accélère la validation mais ne remplace pas l'analyse du contexte, des privilèges de la base et de l'impact.
HTML
Entrée injectée dans le HTML généré.
<img src=x onerror=alert(1)>
Attribut
Le contexte d'attribut nécessite une rupture adaptée.
" onfocus=alert(1) x="
JavaScript
Le contexte JS est différent et doit être analysé séparément.
Types : reflected, stored et DOM-based. Pour chaque cas, documenter la source, le sink, le contexte et le navigateur concerné.
Workflow
Peut-on sauter une étape ou appeler directement l'étape finale ?
Limites
Existe-t-il une limite sur les tentatives, quantités, montants ou actions répétées ?
Concurrence
Deux requêtes simultanées produisent-elles un état incohérent ?
Les tests métier nécessitent de comprendre le scénario normal avant de chercher une violation. Les réponses HTTP seules ne suffisent pas toujours : vérifier l'état réel de la ressource.
Session
- Rotation après authentification
- Expiration
- Invalidation après logout
- Attributs Secure / HttpOnly / SameSite
Reset Password
- Token imprévisible
- Expiration
- Usage unique
- Pas de fuite dans URL, logs ou réponses
Tester séparément : création de session, maintien de session, changement de privilège, logout et récupération de compte.
Données non fiables
Identifier les mécanismes qui reconstruisent des objets ou structures à partir de données contrôlées par l'utilisateur.
Chaîne de confiance
Vérifier que les mises à jour, plugins ou artefacts sont authentifiés et que leur intégrité est contrôlée.
La désérialisation dangereuse peut avoir un impact important selon le framework, le gadget chain et les privilèges du processus. Ne pas conclure uniquement à partir du format observé.
Événement
Connexion échouée, modification de privilège, accès sensible, erreur applicative.
Trace
Utilisateur, source, timestamp, endpoint, résultat.
Alerte
Existe-t-il une règle ou un mécanisme permettant de détecter l'événement ?
Dans un test autorisé, coordonner les vérifications avec l'équipe de supervision pour distinguer « événement non journalisé » de « événement journalisé mais non alerté ».
Fail-Open
Une erreur de dépendance ou d'état conduit involontairement à autoriser l'action.
Exemple : contrôle externe indisponible → accès accordé.
Fail-Closed
En cas d'incertitude ou d'erreur, l'opération sensible est refusée ou suspendue.
Tester les chemins d'erreur de façon contrôlée : timeout, réponse invalide, session expirée, dépendance indisponible, paramètres manquants.
FFUF
ffuf -w wordlist.txt -u https://cible.exemple/FUZZ
ffuf -w wordlist.txt -u https://cible.exemple/FUZZ -mc 200,204,301,302,307,401,403
Gobuster
gobuster dir -u https://cible.exemple -w wordlist.txt
gobuster dir -u https://cible.exemple -w wordlist.txt -x php,txt,bak
Interprétation : filtrer par code ne suffit pas. Comparer taille, mots, lignes et comportement des réponses pour éliminer les faux positifs.
Une même adresse IP peut servir plusieurs applications selon le nom d'hôte fourni par le client. La découverte de vhosts peut donc révéler une surface différente de celle du domaine principal.
# Tester un Host précis
curl -k -H "Host: admin.cible.exemple" https://IP/
# Avec ffuf
ffuf -w subdomains.txt -u https://IP/ -H "Host: FUZZ.cible.exemple"
Toujours vérifier le scope : la découverte d'un vhost ne signifie pas automatiquement que son exploitation est autorisée.
→
HTTP History
Cartographier
→
→
À chaque requête
- Méthode
- Endpoint
- Paramètres
- Cookies / Authorization
- Content-Type
- Réponse et timing
Réflexe
Envoyer une requête intéressante vers Repeater, modifier une seule variable, puis comparer avec la réponse de référence.
Status
200, 201, 302, 400, 401, 403, 404, 500...
Contenu
Taille, mots, JSON, champs présents/absents, messages d'erreur.
Comportement
Redirection, cookie, timing, changement d'état côté serveur.
Exemple : un endpoint peut renvoyer HTTP 200 aussi bien pour une opération réussie que pour une erreur métier contenue dans JSON. Toujours inspecter la réponse complète.
Reproductibilité
Un tiers doit pouvoir reproduire le comportement avec les mêmes préconditions.
Impact
Décrire ce qui est réellement obtenu : données, action, privilège ou disponibilité.
Limites
Documenter ce qui n'a pas été tenté ou ce qui dépend d'une condition particulière.
Éviter les affirmations disproportionnées : démontrer précisément ce que la preuve établit, puis séparer l'impact observé des scénarios potentiels.
1. Endpoint identifié ? → non : poursuivre la découverte. → oui : capturer la requête.
2. Authentification requise ? → tester anonymous / user / privileged selon le scope.
3. Paramètre contrôlé ? → identifier son emplacement et son contexte.
4. Contrôle de sécurité observable ? → modifier une variable et comparer à la référence.
5. Anomalie reproductible ? → confirmer l'impact, limiter l'exploitation, documenter.
Recon
- Technologies
- Endpoints
- Vhosts
- Fichiers / répertoires
- API
Tests
- Access control
- Auth/session
- Injection
- Misconfiguration
- Business logic
Validation finale
Reproduire → capturer la preuve → mesurer l'impact → documenter les préconditions → proposer une correction ciblée.
Checklist Pratique — Web Application Pentesting
- 1. Toujours partir du référentiel OWASP Top 10:2025 pour structurer les tests et le rapport final.
- 2. Contrôle d'accès (A01) et configuration (A02) sont désormais les deux risques prioritaires — à tester systématiquement en premier.
- 3. Injection (A05) : tester manuellement avant d'automatiser avec SQLMap — comprendre pourquoi ça marche évite les faux négatifs.
- 4. Fuzzing de contenu (ffuf/gobuster) en complément du crawling pour ne rien laisser dans l'angle mort.
- 5. Burp Suite reste l'outil central : proxy, Repeater et Intruder couvrent l'essentiel des tests manuels.
- 6. Les nouvelles catégories 2025 (chaîne logicielle, gestion des erreurs) rappellent que la sécurité web dépasse le code applicatif seul.