Les applications web sont aujourd'hui la surface d'attaque la plus exposée de toute organisation connectée. Portails clients, APIs REST et GraphQL, back-offices, interfaces de gestion industrielle, applications SaaS internes : chaque endpoint HTTP représente une porte d'entrée potentielle pour un attaquant.
L'exploitation des applications web désigne l'ensemble des techniques utilisées pour identifier et compromettre ces points d'entrée, escalader des privilèges, exfiltrer des données ou prendre le contrôle de systèmes critiques. Comprendre ces mécanismes n'est pas réservé aux équipes offensives : pour un DSI, un RSSI ou un architecte logiciel, connaître les vecteurs d'attaque réels permet de prioriser les investissements sécurité et d'évaluer la pertinence d'un audit applicatif.
Chiffres clés : 75 % des cyberattaques ciblent la couche applicative (Gartner) et 84 % des applications web contiennent au moins une vulnérabilité critique (Veracode 2024). La majorité des incidents n'exploitent pas des zero-days : ils tirent parti de vulnérabilités connues, documentées, présentes dans des applications qui n'ont jamais été testées.
Pourquoi les applications web sont-elles la cible préférée des attaquants ?
L'application web concentre trois facteurs d'attractivité pour un attaquant : elle est accessible depuis n'importe où sans présence physique, elle traite des données à haute valeur (identifiants, données financières, données de production), et elle constitue souvent le maillon le moins surveillé de la chaîne de sécurité.
La surface d'attaque s'est considérablement élargie ces dernières années avec la multiplication des APIs, des micro-services, des intégrations tierces et des environnements cloud. Là où une application web des années 2010 exposait quelques dizaines d'endpoints, une application SaaS moderne peut en exposer plusieurs milliers, chacun représentant un vecteur d'exploitation potentiel.
Le référentiel OWASP Top 10 : la carte des vulnérabilités à connaître
L'OWASP publie depuis 2003 son classement des dix vulnérabilités les plus critiques dans les applications web. Ce référentiel est le standard mondial de l'audit de sécurité applicative. Voici les catégories les plus exploitées en conditions réelles.
A01 : Broken Access Control, la vulnérabilité la plus exploitée
Le contrôle d'accès défaillant occupe la première place du classement OWASP depuis 2021. Il désigne toute situation où un utilisateur peut accéder à des ressources ou des fonctions auxquelles il ne devrait pas avoir accès.
Le cas le plus courant est l'IDOR (Insecure Direct Object Reference) : l'application utilise un identifiant prévisible dans ses URLs ou ses paramètres de requête. Un attaquant modifie cet identifiant pour accéder aux données d'autres utilisateurs.
Exemple concret en test d'intrusion applicatif :
GET /api/factures/1042 → modifié en /api/factures/1043 → accès aux données d'un autre client
Variante plus grave : la vertical privilege escalation, où un utilisateur standard accède à des fonctions réservées aux administrateurs en manipulant directement les paramètres de requête ou les headers HTTP, sans aucune vérification côté serveur.
Impacts métier : exfiltration de données clients sans compromission de compte admin, accès aux données financières d'autres entreprises sur une plateforme SaaS multi-tenant, modification de données appartenant à d'autres utilisateurs.
A02 : Cryptographic Failures, quand les données sensibles voyagent en clair
Cette catégorie couvre tous les cas où des données sensibles sont insuffisamment protégées : transmission en clair, algorithmes obsolètes, gestion défaillante des clés, stockage de mots de passe sans hachage correctement salé.
Exemples fréquemment identifiés lors d'un pentest web :
- Token JWT signé avec l'algorithme none : l'attaquant forge son propre token avec des droits administrateur sans connaître la clé secrète.
- Mots de passe hachés en MD5 : des tables arc-en-ciel permettent de retrouver les mots de passe en quelques secondes après une fuite de base de données.
- Cookies de session transmis en HTTP : interceptables sur un réseau non chiffré ou via une injection de contenu mixte.
A03 : Injection SQL et injection de commandes
Les injections reposent toutes sur le même principe : des données fournies par l'utilisateur sont interprétées comme des instructions par le serveur, faute de validation et de séparation correctes.
L'injection SQL permet à un attaquant de manipuler les requêtes envoyées à la base de données pour extraire, modifier ou supprimer des données, voire exécuter des commandes système. Des outils comme sqlmap automatisent la détection et l'exploitation, mais un auditeur expert ira bien au-delà : extraction de schémas, dumps de tables de credentials, accès au système de fichiers.
L'injection de commandes OS survient quand une application appelle des commandes système avec des paramètres utilisateur non filtrés. Ce type de vulnérabilité est particulièrement fréquent dans les interfaces d'administration, les outils de diagnostic réseau intégrés, et les panneaux de configuration industriels (HMI). Une mission de pentest industriel couvre systématiquement ce vecteur.
La SSTI (Server-Side Template Injection) cible les moteurs de templates (Jinja2, Twig, Freemarker). Si les données utilisateur sont insérées directement dans un template sans neutralisation, un attaquant peut exécuter du code serveur arbitraire et obtenir un shell sur le serveur.
A04 : Insecure Design, les vulnérabilités architecturales
Cette catégorie s'intéresse non pas aux erreurs d'implémentation, mais aux défauts de conception. Une logique métier mal modélisée, des flux d'authentification insuffisamment sécurisés : ces vulnérabilités sont les plus difficiles à corriger car elles nécessitent souvent de revoir l'architecture.
Exemple typique : une application de commande en ligne qui valide le paiement côté client. Un attaquant intercepte la requête et modifie le montant avant de l'envoyer au serveur, qui l'accepte sans re-vérification. Ce type de faille n'est détectable que par un auditeur humain qui comprend la logique métier.
A05 : Security Misconfiguration, la surface d'attaque invisible
Les mauvaises configurations représentent une part importante des vulnérabilités trouvées en audit de sécurité. Elles couvrent un périmètre très large :
- Headers de sécurité absents : absence de Content-Security-Policy (CSP), X-Frame-Options, HSTS. Facilite les attaques XSS et clickjacking.
- Interfaces d'administration exposées : panels phpMyAdmin, Kibana, Grafana accessibles publiquement sans authentification.
- Messages d'erreur verbeux : traces de stack, chemins de fichiers, versions de frameworks exposés dans les réponses HTTP.
- Fonctionnalités de debug actives en production : endpoints /debug, /status, /metrics exposant l'état interne de l'application.
- Permissions excessives sur les buckets cloud : stockage S3 ou Azure Blob en lecture publique contenant des données sensibles ou des fichiers de configuration.
A07 : Identification and Authentication Failures
Les mécanismes d'authentification défaillants sont un vecteur d'exploitation des applications web extrêmement courant. Au-delà du mot de passe trop simple, les failles d'authentification comprennent :
- Absence de protection contre le brute force : aucune limitation des tentatives de connexion.
- Reset de mot de passe prévisible : tokens de réinitialisation courts, non expirés, ou transmis via un canal non sécurisé.
- Session fixation : l'identifiant de session n'est pas régénéré après authentification.
- Tokens JWT mal validés : vérification de signature désactivée, algorithme modifiable par l'attaquant, durée de vie excessive.
- Failles OAuth2 : state parameter absent ou prévisible, redirect_uri mal validée, autorisation accordée sans consentement explicite.
Toutes nos missions sont spécifiques, parce que vos enjeux le sont
Le pentest applicatif est avant tout une philosophie qui, couplée à nos compétences techniques offensives, s'adapte à chaque cible : SaaS multi-tenant, API industrielle, back-office métier, application mobile. PIIRATES identifie les vulnérabilités que les scanners ne voient jamais.
Indépendance totale
Expertise offensive
Professionnalisme
Techniques avancées d'exploitation des applications web
Au-delà du Top 10 OWASP, certaines techniques d'exploitation méritent une attention particulière car elles sont en forte progression et souvent sous-estimées par les équipes défensives.
XSS (Cross-Site Scripting) : du vol de cookie à la compromission de compte
Le XSS permet à un attaquant d'injecter du code JavaScript malveillant dans les pages consultées par d'autres utilisateurs. Trois variantes existent : le XSS réfléchi (le payload est dans l'URL), le XSS stocké (le payload est persisté en base de données, il touche tous les visiteurs), et le DOM-based XSS (exploitation de la manipulation du DOM côté client).
En pentest applicatif, le XSS stocké est souvent le plus critique : un payload injecté dans un commentaire ou un champ de formulaire s'exécute automatiquement pour chaque utilisateur qui consulte la page. Les impacts vont du simple vol de cookie de session à la mise en place de keyloggers dans l'application, la capture de formulaires ou le contournement de MFA via la manipulation de l'interface.
SSRF (Server-Side Request Forgery) : pivoter vers les systèmes internes
La SSRF est l'une des vulnérabilités dont l'impact a le plus augmenté avec la migration vers le cloud. Elle permet à un attaquant de forcer le serveur à effectuer des requêtes HTTP vers des ressources internes, inaccessibles directement depuis l'extérieur.
En environnement cloud AWS, Azure ou GCP, une SSRF permet classiquement d'accéder au service de métadonnées de l'instance pour récupérer les credentials IAM, puis de pivoter vers l'ensemble des ressources cloud de l'organisation : buckets S3, bases RDS, secrets Manager. C'est un vecteur systématiquement testé dans les pentests applicatifs sur des environnements cloud.
XXE (XML External Entity Injection)
L'injection XXE affecte les applications qui traitent des données XML. Si le parseur XML est mal configuré, un attaquant peut définir des entités externes pointant vers des fichiers locaux du serveur ou des services internes. Cela peut mener à la lecture de fichiers sensibles (/etc/passwd, fichiers de configuration avec des credentials), à un SSRF interne, ou dans certains cas à un déni de service.
Les APIs qui acceptent du XML, les fonctionnalités d'import de fichiers (XML, DOCX, SVG) et les webservices SOAP sont les cibles principales de ce vecteur d'exploitation des applications web.
Insecure Deserialization : exécution de code arbitraire
Quand une application désérialise des objets fournis par l'utilisateur sans validation, un attaquant peut construire des objets malveillants dont la désérialisation déclenche l'exécution de code arbitraire (RCE). Cette vulnérabilité est particulièrement présente dans les applications Java (bibliothèques Commons Collections), PHP et Python, ainsi que dans les APIs qui acceptent des formats de sérialisation binaires ou des objets JSON complexes.
Upload de fichiers malveillants
Les fonctionnalités d'upload de fichiers sont un vecteur d'exploitation fréquemment négligé. Quand la validation côté serveur est insuffisante, un attaquant peut téléverser un script PHP, un fichier HTML contenant du JavaScript malveillant, ou un fichier dont l'exécution provoque une prise de contrôle du serveur. La vérification du type MIME côté client est triviale à contourner : seule la validation côté serveur, du contenu réel du fichier, est fiable.
Business Logic Vulnerabilities : les failles invisibles aux scanners
Les vulnérabilités de logique métier sont les plus redoutables dans le contexte de l'exploitation des applications web, car elles sont totalement invisibles aux outils de scan automatique. Elles exploitent des incohérences dans le comportement attendu de l'application.
Exemples concrets identifiés en mission chez PIIRATES :
- Code promo appliqué plusieurs fois : l'application valide le code à chaque étape du workflow mais ne vérifie pas son utilisation globale, permettant des remises infinies.
- Validation de paiement contournable : modification du statut de la commande via un paramètre caché avant confirmation côté serveur.
- Race condition sur les opérations financières : deux requêtes simultanées de retrait passent toutes les deux alors que le solde ne le permet qu'une.
- Transfert de droits non contrôlé : la suppression d'un utilisateur réassigne ses droits d'administration à d'autres membres sans validation.
Ces vulnérabilités représentent la différence fondamentale entre un audit grey box conduit par un expert et un scan de vulnérabilités automatisé.
Exploitation des APIs : la surface d'attaque qui croît le plus vite
Les APIs REST, GraphQL et SOAP sont devenues le principal mode de communication entre composants d'applications modernes. Elles représentent aussi une surface d'attaque spécifique, couverte par l'OWASP API Security Top 10.
API1 : Broken Object Level Authorization
L'équivalent API de l'IDOR. Les APIs exposent directement des identifiants d'objets dans leurs endpoints sans vérifier que l'appelant est bien autorisé à accéder à l'objet référencé. En GraphQL, cette faille prend souvent la forme d'une introspection non désactivée permettant de cartographier l'ensemble du schéma de données, puis d'accéder à des champs normalement non exposés.
API3 : Broken Object Property Level Authorization
L'API retourne des objets complets contenant des champs sensibles (salaires, données médicales, mots de passe hashés) que le front-end n'affiche pas mais qui sont présents dans la réponse JSON. Un attaquant qui intercepte les réponses API accède à bien plus d'informations que ce que l'interface présente.
API8 : Security Misconfiguration spécifique aux APIs
Absence de rate limiting sur les endpoints d'authentification, CORS mal configuré permettant des requêtes cross-origin non autorisées, méthodes HTTP non restreintes (DELETE, PUT accessibles sans vérification), clés API exposées dans le code source ou les headers de réponse. Ces configurations incorrectes sont systématiquement recherchées lors d'un pentest d'exploitation d'applications web.
Méthodologie d'un pentest d'exploitation d'applications web
Un test d'intrusion applicatif conduit selon les standards de l'industrie ne se résume pas à lancer un scanner et exporter les résultats. Il suit une méthodologie structurée qui garantit une couverture complète et des résultats exploitables.
Phase 1 : Reconnaissance et cartographie
L'auditeur cartographie la surface d'attaque : identification de tous les endpoints (URLs, paramètres, méthodes HTTP), des technologies utilisées (frameworks, serveurs, bases de données), des mécanismes d'authentification et de gestion de session. Les outils comme Burp Suite, ffuf ou gobuster sont utilisés pour la découverte automatisée, mais c'est l'analyse manuelle qui identifie les endpoints non documentés et les paramètres cachés. En parallèle, une phase OSINT permet d'identifier les fuites d'information accessibles publiquement.
Phase 2 : Tests d'authentification et de gestion de session
Chaque mécanisme d'authentification est testé : politique de mots de passe, protection anti-brute force, reset de mot de passe, gestion des tokens (JWT, OAuth2, cookies de session). Les flux OAuth2 sont analysés pour détecter les failles de configuration du state parameter et de la redirect_uri. Les sessions sont analysées pour détecter les failles de fixation, d'expiration et de révocation.
Phase 3 : Tests d'autorisation et d'accès aux données
C'est la phase où les vulnérabilités IDOR et de contrôle d'accès sont testées systématiquement. L'auditeur cartographie les rôles et les droits, puis tente d'accéder horizontalement (un utilisateur accède aux données d'un autre) et verticalement (un utilisateur standard accède à des fonctions admin). Cette phase est particulièrement critique pour les plateformes SaaS multi-tenant où l'isolation des données entre clients doit être parfaite.
Phase 4 : Tests d'injection et de validation des entrées
Tous les points d'entrée identifiés sont testés pour les injections SQL, les injections de commandes, le XSS, la SSTI, les injections XXE, les injections LDAP et les injections NoSQL. L'auditeur utilise à la fois des outils automatisés et des payloads manuels pour dépasser les protections WAF et les filtres de validation basiques.
Phase 5 : Logique métier et scénarios enchaînés
La phase la plus spécifique à l'expertise humaine : l'auditeur explore les workflows métier pour identifier les incohérences, tente des contournements d'étapes, enchaîne plusieurs vulnérabilités mineures pour atteindre un impact critique. C'est ici que se révèle la valeur d'un audit conduit par des experts offensifs plutôt que par des outils automatisés.
Phase 6 : Rapport et plan de remédiation
Le rapport final documente chaque vulnérabilité avec : preuve d'exploitation (screenshot, requête HTTP brute), criticité selon le CVSS, impact métier concret, et recommandation de correction actionnable. Un bon rapport de pentest doit être lisible par la DSI, le RSSI et le développeur qui va corriger. PIIRATES fournit systématiquement un plan de remédiation priorisé et une présentation COMEX.
Étude de cas : exploitation d'une plateforme SaaS B2B lors d'un pentest PIIRATES
Mission : pentest applicatif grey box d'une plateforme SaaS de gestion de contrats, 3 rôles utilisateurs (admin, manager, lecteur), API REST et interface GraphQL.
Résultats de la mission sur 5 jours :
- 14 vulnérabilités identifiées dont 4 critiques et 5 hautes.
- IDOR sur l'endpoint /api/contrats/{id} : accès à l'intégralité des contrats de tous les clients de la plateforme avec un compte lecteur standard.
- Introspection GraphQL non désactivée : cartographie complète du schéma de données, découverte d'un champ salaire non exposé dans l'interface mais présent dans les réponses.
- Race condition sur la validation de signature électronique : deux requêtes simultanées permettaient de signer un contrat avec un compte dont la signature avait été révoquée.
- XSS stocké dans le champ commentaire des contrats : exécution de code JavaScript pour tous les utilisateurs consultant le contrat.
- JWT signé sans expiration et avec un algorithme modifiable : forge de token avec droits admin sans connaissance de la clé secrète.
Impact démontré : exfiltration de l'ensemble des contrats de tous les clients de la plateforme, prise de contrôle de n'importe quel compte utilisateur. Aucune de ces vulnérabilités n'avait été détectée par le scan automatique réalisé trois mois plus tôt.
Plan de remédiation sur 30 jours : correction des contrôles d'accès, désactivation de l'introspection GraphQL en production, mise en place de la vérification de signature JWT côté serveur. Surface d'attaque réduite de 90 %.
Scan automatique contre audit expert : ce que les outils ne voient jamais
Les outils de scan de vulnérabilités (DAST comme OWASP ZAP, Nikto, Acunetix) ont une utilité réelle dans un pipeline DevSecOps. Mais ils présentent des limites structurelles qui rendent un audit expert irremplaçable.
- ✕ Vulnérabilités de logique métier : totalement invisibles aux scanners, qui ne comprennent pas ce que l'application est censée faire.
- ✕ Chaînage de vulnérabilités : un scanner ne combine pas une IDOR avec un SSRF pour démontrer un impact critique. Un auditeur expert si.
- ✕ Contexte d'authentification profond : les scanners peinent à naviguer dans des flux OAuth2, MFA ou SSO complexes, laissant une grande partie de l'application non testée.
- ✕ Faux positifs en volume : un scan génère typiquement 60 à 80 % de faux positifs qui masquent les vraies vulnérabilités.
- ✕ Absence de preuve d'exploitation : un scanner signale une vulnérabilité potentielle. Un auditeur démontre son exploitation réelle avec un impact mesurable.
Comment se protéger contre l'exploitation des applications web ?
La correction des vulnérabilités identifiées en audit est nécessaire mais insuffisante. Une approche durable s'appuie sur plusieurs pratiques complémentaires.
Sécurité by design dès la conception
Intégrer les exigences de sécurité dans les user stories et les critères d'acceptation. Un contrôle d'accès bien conçu dès le début coûte infiniment moins cher qu'une refonte architecturale post-audit. La formation sécurité applicative des développeurs est un investissement à fort retour sur investissement.
Tests de sécurité dans le pipeline CI/CD
Intégrer des analyses SAST (analyse statique du code) et des tests DAST automatisés dans le pipeline de déploiement. Ces outils ne remplacent pas un pentest applicatif, mais permettent de détecter les vulnérabilités connues avant qu'elles atteignent la production. PIIRATES accompagne les équipes sur l'intégration de ces contrôles dans leurs workflows de développement.
Gestion rigoureuse des dépendances
La majorité des applications web modernes intègrent des centaines de bibliothèques tierces. Un composant vulnérable dans votre chaîne de dépendances est une porte d'entrée directe. Les outils SCA (Software Composition Analysis) permettent de surveiller les CVE affectant les bibliothèques utilisées. Les équipes DevSecOps de PIIRATES peuvent accompagner la mise en place de ces contrôles automatisés.
Protection périmétrique complémentaire
Un WAF correctement configuré (Cloudflare, AWS WAF, ModSecurity) filtre les attaques connues et les payloads automatisés avant qu'ils n'atteignent l'application. Il ne remplace pas le code sécurisé mais réduit significativement la surface d'attaque exposée.
Pentests réguliers par des experts offensifs
Un audit de sécurité applicatif conduit par des experts est indispensable au moins une fois par an, et à chaque évolution majeure de l'application. Il permet d'identifier les vulnérabilités logiques, de valider l'efficacité des mesures correctives précédentes et de maintenir une posture de sécurité cohérente avec le niveau de menace réel.
Pour les organisations qui souhaitent faire auditer leurs applications web, APIs ou interfaces industrielles, PIIRATES propose des tests d'intrusion applicatifs couvrant l'ensemble des vecteurs d'exploitation décrits dans cet article : OWASP Web Top 10, OWASP API Security Top 10, logique métier, APIs REST/GraphQL, authentification OAuth2 et MFA.
Nos coordonnées
- 04 28 49 00 25
- contact@piirates.fr
- 6 Rue Denis Papin
07130 Saint Peray
Envoyez nous un ping
Exploitation des applications web : techniques, vulnérabilités OWASP, impacts métier et méthodes de pentest pour sécuriser vos applications en 2024.
