En bref : La surface d'attaque moyenne d'une entreprise s'est étendue d'un facteur 10 au cours des cinq dernières années. Les API dépassent désormais les pages web en nombre. Les microservices ont remplacé les monolithes. L'infrastructure cloud introduit des classes de vulnérabilités entièrement nouvelles -- escalade de privilèges IAM, exploitation de services de métadonnées, mauvaise configuration de buckets de stockage -- que les méthodologies de pentesting traditionnelles n'ont jamais été conçues pour couvrir. Pourtant, la plupart des organisations définissent encore le périmètre de leur pentest annuel de la même manière qu'en 2019 : une application web, un scan réseau externe. Le résultat est une illusion dangereuse de sécurité. Ce guide couvre à quoi ressemblent réellement les surfaces d'attaque modernes, les classes de vulnérabilités spécifiques que vos pentests actuels manquent probablement, et comment définir un périmètre de test couvrant l'ensemble du paysage.
En 2019, le périmètre typique d'un pentest d'entreprise ressemblait à ceci : une ou deux applications web, une plage d'adresses IP externes, et peut-être un segment de réseau interne. L'engagement durait deux semaines. Le testeur trouvait du XSS, de l'injection SQL, du SSL mal configuré, quelques en-têtes de sécurité manquants et une poignée de mots de passe faibles. Le rapport faisait 150 pages. Les résultats étaient familiers.
En 2026, la même entreprise possède 200 microservices communiquant via 1 500 endpoints API. Son infrastructure s'étend sur trois fournisseurs cloud. Les pipelines CI/CD déploient du code 50 fois par jour. Les intégrations SaaS tierces se comptent par dizaines, chacune avec ses propres clés API et tokens OAuth. Des clusters Kubernetes orchestrent des conteneurs qui se créent et se terminent en minutes. Des fonctions serverless exécutent de la logique métier sans serveur traditionnel à scanner.
La surface d'attaque s'est étendue d'un ordre de grandeur. Mais pour de nombreuses organisations, le périmètre du pentest n'a pas changé du tout.
L'ampleur de l'expansion de la surface d'attaque
Les chiffres quantifient ce que les équipes de sécurité ressentent intuitivement. Un rapport 2025 de l'Enterprise Strategy Group a révélé que 67 % des organisations ont connu une augmentation significative de leur surface d'attaque externe au cours des 24 mois précédents. L'entreprise moyenne gère désormais 3,5 fois plus d'actifs exposés sur internet qu'en 2020.
Les API sont le vecteur de croissance le plus spectaculaire. Le rapport 2024 d'Akamai sur l'état d'internet a révélé que le trafic API représente désormais 83 % de tout le trafic web, contre environ 60 % en 2020. L'entreprise moyenne expose plus de 600 endpoints API, et les équipes de sécurité connaissent environ 400 d'entre eux. Les 200 restants -- des API fantômes créées par les équipes de développement sans revue de sécurité -- représentent une surface d'attaque inconnue et non testée.
L'adoption du cloud a été tout aussi transformatrice. Gartner projette que plus de 95 % des nouvelles charges de travail numériques seront déployées sur des plateformes cloud-native d'ici 2026. Chaque déploiement cloud introduit de nouveaux types d'actifs qui n'existaient pas dans l'infrastructure traditionnelle : rôles IAM, groupes de sécurité, politiques de stockage, comptes de service, instances de bases de données gérées, fonctions serverless et configurations d'orchestration de conteneurs. Ce ne sont pas des « hôtes » traditionnels -- ce sont des constructions de politiques et des objets de configuration qui peuvent être tout aussi exploitables qu'un serveur web vulnérable.
L'architecture microservices qui permet le développement rapide multiplie également la complexité de sécurité. Une application monolithique avait une seule surface d'attaque -- l'application elle-même. Une architecture microservices avec 200 services a 200 surfaces d'attaque, chacune avec son propre modèle d'authentification, ses schémas d'accès aux données et ses canaux de communication. Chaque chemin de communication inter-service est une opportunité potentielle de mouvement latéral. Chaque compte de service est un vecteur potentiel d'escalade de privilèges.
Ce que les pentests traditionnels manquent
L'écart entre ce que le pentesting traditionnel couvre et ce que les surfaces d'attaque modernes exposent n'est pas une fissure étroite -- c'est un gouffre. Voici les classes de vulnérabilités spécifiques que les tests d'intrusion standard d'applications web et de réseaux n'évaluent typiquement pas.
Vulnérabilités spécifiques aux API
Les tests traditionnels d'applications web se concentrent sur les interactions basées sur le navigateur : formulaires, rendu de pages, cookies de session et le flux applicatif visible par l'utilisateur. Les API opèrent en dessous de cette couche et possèdent leur propre taxonomie de vulnérabilités.
Le OWASP API Security Top 10 identifie les risques les plus critiques spécifiques aux API :
Broken Object Level Authorization (BOLA) est la vulnérabilité API la plus répandue, trouvée dans environ 40 % des API selon le rapport 2025 de Salt Security sur l'état de la sécurité API. Le BOLA se produit lorsqu'un endpoint API accepte un identifiant d'objet (ID utilisateur, numéro de compte, ID de commande) et ne vérifie pas que l'utilisateur authentifié a la permission d'accéder à cet objet. Un attaquant change l'ID dans la requête et accède aux données d'un autre utilisateur.
Les tests d'applications web traditionnels peuvent détecter le BOLA si le testeur manipule manuellement les paramètres, mais le test BOLA systématique sur des centaines d'endpoints API nécessite une méthodologie de sécurité API dédiée. Un testeur consacrant 80 % de son temps aux tests basés sur le navigateur n'aura pas les heures nécessaires pour tester chaque endpoint pour les contournements d'autorisation.
Broken Function Level Authorization se produit lorsque les endpoints API ne restreignent pas correctement l'accès aux fonctions d'administration. Un utilisateur ordinaire découvre que l'endpoint de création d'utilisateur admin existe à /api/admin/users/create et l'appelle directement. Les tests web traditionnels suivent l'interface utilisateur de l'application, qui n'expose pas les endpoints d'administration aux utilisateurs ordinaires. Les tests API énumèrent tous les endpoints indépendamment de la visibilité dans l'interface.
Mass Assignment exploite les API qui lient automatiquement les paramètres de requête aux champs du modèle de données interne. Un endpoint de mise à jour de profil utilisateur qui accepte {"name": "Jean"} peut aussi accepter {"name": "Jean", "role": "admin"} si l'API ne liste pas explicitement les champs autorisés. Cette vulnérabilité est invisible pour les tests web traditionnels car le formulaire du navigateur ne soumet que les champs attendus.
Excessive Data Exposure se produit lorsque les API retournent des objets de données complets et s'appuient sur l'application côté client pour filtrer ce qui est affiché à l'utilisateur. La réponse API pour un profil utilisateur peut inclure le numéro de sécurité sociale, le salaire et des notes internes, même si l'interface web n'affiche que le nom et l'email. Un test web traditionnel voit l'interface filtrée. Un test API examine la réponse brute et découvre la fuite de données.
Vecteurs d'attaque cloud-natifs
L'infrastructure cloud introduit des classes de vulnérabilités qui n'ont pas d'équivalent dans les environnements traditionnels sur site.
L'escalade de privilèges IAM est l'équivalent cloud de l'escalade de privilèges Active Directory. AWS seul possède plus de 15 000 permissions IAM distinctes. Le rapport 2024 de Datadog sur l'état de la sécurité cloud a révélé que 18 % des instances EC2 AWS ont des rôles IAM avec des chemins d'escalade de privilèges élevés ou critiques. Les pentests traditionnels n'évaluent pas les politiques IAM -- cela nécessite des tests de sécurité cloud dédiés.
L'exploitation du service de métadonnées permet à un attaquant disposant d'un Server-Side Request Forgery (SSRF) d'atteindre le service de métadonnées de l'instance cloud et de récupérer les identifiants IAM. La violation de Capital One de 2019 -- exposant 100 millions de dossiers clients -- a utilisé exactement cette chaîne : SSRF vers le service de métadonnées vers l'extraction d'identifiants. Les tests web traditionnels peuvent trouver le SSRF mais ne suivront pas le chemin d'exploitation spécifique au cloud.
La mauvaise configuration des buckets de stockage persiste. L'analyse 2025 d'Orca Security a révélé que 36 % des actifs de stockage cloud ont au moins une mauvaise configuration, avec 7 % accessibles publiquement. Le pentesting traditionnel ne découvrira pas un bucket S3 publiquement listable parce qu'il fait partie de l'infrastructure cloud, pas de l'application web.
La sécurité des conteneurs et de Kubernetes introduit des vulnérabilités d'évasion, l'exposition de secrets, des comptes de service trop permissifs et des violations de politiques de sécurité des pods. Les chaînes d'attaque traversant les couches application, conteneur et orchestration nécessitent une méthodologie que le pentesting traditionnel couvre rarement.
Attaques de pipelines CI/CD
Le pipeline de livraison logicielle est lui-même devenu une surface d'attaque. Les systèmes CI/CD ont accès au code source, aux identifiants de déploiement, aux clés de fournisseurs cloud et à l'infrastructure de production. Les vecteurs d'attaque courants incluent l'exécution empoisonnée du pipeline (injection de code via des configurations de pipeline modifiées par PR), l'extraction de secrets des variables d'environnement CI/CD, la falsification d'artefacts de build et les attaques de confusion de dépendances.
Comme couvert dans notre guide sur le pentesting dans le pipeline DevOps, le pipeline est à la fois un outil de test et une cible de test. La plupart des organisations l'utilisent pour le premier sans considérer le second.
Risques d'intégration tierce
Les applications modernes dépendent de dizaines de services tiers, chacun créant des frontières de confiance qui peuvent être exploitées via une mauvaise configuration des tokens OAuth, des endpoints de webhook non authentifiés ou des clés API exposées dans le code côté client. Le pentesting traditionnel couvre rarement ces points d'intégration car ils traversent les frontières organisationnelles -- mais les attaquants ne respectent pas les limites de périmètre.
Le problème de périmètre : tester ce que vous avez testé l'année dernière
Le schéma le plus dangereux dans la définition du périmètre de pentest est l'inertie. Les organisations définissent le périmètre de leur premier pentest en fonction de ce qu'elles croient être leur surface d'attaque à ce moment-là. Chaque pentest ultérieur utilise essentiellement le même périmètre -- les mêmes applications, les mêmes plages IP, la même méthodologie -- avec des ajustements mineurs.
Pendant ce temps, la surface d'attaque réelle évolue continuellement. De nouvelles API sont déployées. Des comptes cloud sont provisionnés. Des microservices sont créés. Des intégrations tierces sont ajoutées. L'orchestration de conteneurs est adoptée. Aucun de ces changements n'est reflété dans le périmètre de pentest parce que personne ne met à jour le document de périmètre.
Le résultat est un pentest qui couvre un pourcentage de plus en plus petit de la surface d'attaque réelle. Si le premier pentest couvrait 80 % des actifs de l'organisation, et que la surface d'attaque a été multipliée par 10 tandis que le périmètre est resté constant, le pentest actuel couvre environ 8 % de la surface d'attaque réelle. Les 92 % restants sont un territoire non testé -- et c'est exactement le territoire où les actifs les plus récents, les moins durcis et les plus susceptibles d'être exploitables résident.
Ce n'est pas un risque théorique. Les données de violations montrent systématiquement que les attaquants ciblent préférentiellement les actifs nouveaux et non surveillés. Un rapport 2025 d'intervention sur incidents de Mandiant a révélé que 64 % des vecteurs d'accès initial impliquaient des actifs inconnus de l'équipe de sécurité ou non inclus dans la dernière évaluation de sécurité. Les actifs que les organisations ne testent pas sont précisément les actifs que les attaquants exploitent.
Comment définir le périmètre pour la surface d'attaque moderne
Combler l'écart entre votre surface d'attaque réelle et le périmètre de votre pentest nécessite une approche fondamentalement différente de la définition du périmètre.
Commencer par la découverte, pas par les suppositions
La définition traditionnelle du périmètre demande « que voulons-nous tester ? ». La bonne question est « qu'est-ce qui existe et pourrait être attaqué ? ». Commencez par la découverte automatisée de la surface d'attaque -- en énumérant les enregistrements DNS, les sous-domaines, les IP exposées sur internet, les applications web, les endpoints API, les services exposés et le stockage cloud -- avant de définir le périmètre du test.
Cette phase de découverte révèle souvent des actifs que l'équipe de sécurité ignorait : des serveurs de développement oubliés, des API fantômes, des environnements de test avec des données de production. Ces actifs inconnus sont les cibles de test les plus prioritaires parce qu'ils sont les plus susceptibles d'être mal configurés et non surveillés.
Catégoriser et hiérarchiser votre surface d'attaque
Tous les actifs ne nécessitent pas la même profondeur de test. Après la découverte, catégorisez les actifs en niveaux de test :
Niveau 1 : test manuel + automatisé complet
- Applications de production traitant des données sensibles (PII, financières, de santé)
- Systèmes d'authentification et d'autorisation
- Passerelles API et endpoints API publics
- IAM cloud et infrastructure d'identité
- Pipelines CI/CD avec accès de déploiement en production
Niveau 2 : test automatisé avec validation manuelle
- Applications internes avec accès authentifié
- Microservices avec communication inter-service
- Stockage cloud et services de données
- Infrastructure d'orchestration de conteneurs
- Endpoints d'intégration tierce
Niveau 3 : scan automatisé et revue de configuration
- Environnements de développement et de staging
- Outils et utilitaires internes
- Systèmes informationnels non sensibles
- Systèmes dépréciés planifiés pour décommissionnement
Cette approche par niveaux alloue les ressources de test proportionnellement au risque, garantissant que les actifs les plus critiques reçoivent les tests les plus approfondis tandis que la surface d'attaque plus large reçoit au moins une couverture automatisée.
Inclure des tests spécifiques au cloud
Les tests de sécurité cloud nécessitent des éléments de périmètre dédiés : chemins d'escalade de privilèges IAM, revue des groupes de sécurité et du peering VPC, contrôles d'accès aux services de stockage (S3, Blob, GCS), exposition du service de métadonnées de calcul, permissions des fonctions serverless et configurations de sécurité des conteneurs. Chacun correspond à un vecteur d'attaque cloud-natif que les tests traditionnels de réseau et d'application ne découvriront pas.
Définir le périmètre des API séparément des applications web
Les tests API nécessitent une définition de périmètre et une méthodologie de test distinctes. Les tests d'applications web qui exercent accessoirement quelques endpoints API ne sont pas la même chose que des tests de sécurité API dédiés. Votre périmètre API devrait inclure : l'inventaire complet des endpoints (idéalement à partir des spécifications OpenAPI/Swagger), tous les mécanismes d'authentification et d'autorisation, tous les rôles utilisateur et leurs permissions au niveau API, les contrôles de limitation de débit, la validation des entrées sur tous les paramètres, l'exposition des données dans les réponses API (pas seulement ce que l'interface affiche) et les workflows de logique métier couvrant plusieurs appels API.
Rendre la définition du périmètre continue, pas annuelle
Le changement le plus critique est de traiter la définition du périmètre comme un processus continu plutôt qu'un exercice annuel. Comme nous l'avons exploré dans notre analyse des tests continus versus évaluations annuelles, le modèle annuel crée un écart croissant entre le périmètre et la réalité.
La surveillance automatisée de la surface d'attaque met continuellement à jour l'inventaire des actifs. Les nouveaux actifs découverts entre les tests sont signalés pour inclusion dans le prochain cycle de test. Les actifs décommissionnés sont retirés. Le périmètre évolue au rythme de l'environnement réel, garantissant que la couverture de test reste représentative.
Comment l'IA découvre et teste les surfaces en expansion
L'ampleur des surfaces d'attaque modernes rend la définition manuelle du périmètre et les tests manuels de plus en plus impraticables. Une organisation avec 1 500 endpoints API, 200 microservices, trois comptes cloud et un cluster Kubernetes ne peut pas être testée de manière exhaustive par une équipe de deux personnes en deux semaines. Le calcul ne fonctionne tout simplement pas.
Les tests alimentés par l'IA résolvent ce problème d'échelle par plusieurs mécanismes.
Découverte et cartographie automatisées des actifs
Les systèmes IA découvrent et cartographient continuellement la surface d'attaque sans configuration manuelle. Ils explorent les applications web, énumèrent les endpoints API, scannent les plages réseau, interrogent les enregistrements DNS et analysent les configurations cloud pour construire une cartographie complète et en temps réel des actifs testables. Cette cartographie se met à jour à mesure que l'environnement change, garantissant que les nouveaux actifs sont identifiés et mis en file d'attente pour test dans les jours suivant le déploiement.
Tests parallèles à grande échelle
Les tests traditionnels sont contraints par la capacité humaine -- un testeur ne peut travailler que sur une cible à la fois. Les tests IA s'exécutent en parallèle sur des centaines de cibles simultanément. Les 1 500 endpoints API peuvent être testés pour les vulnérabilités BOLA dans le temps qu'il faudrait à un testeur humain pour tester manuellement 30 d'entre eux. Comme détaillé dans notre article sur les tests parallèles alimentés par l'IA, le parallélisme est l'un des avantages les plus significatifs des tests de sécurité pilotés par l'IA.
Intelligence de test cloud-native
Les plateformes de test IA intègrent des connaissances spécifiques aux fournisseurs cloud -- les plus de 15 000 permissions IAM AWS, la hiérarchie RBAC Azure, le modèle de compte de service GCP -- permettant le test de l'escalade de privilèges et des vulnérabilités de configuration sans que le testeur doive être expert du modèle de sécurité de chaque fournisseur cloud.
Ajustement adaptatif du périmètre
Les systèmes IA adaptent le périmètre de test en fonction de ce qu'ils découvrent pendant l'engagement. Une API fantôme trouvée pendant les tests est testée immédiatement sans attendre l'approbation du périmètre. Un nouveau microservice déployé en cours d'engagement est détecté et inclus automatiquement. La couverture de test reflète l'environnement réel au moment du test, pas l'environnement tel qu'il était compris des semaines plus tôt.
Mesures pratiques pour les responsables de la sécurité
Combler l'écart entre le périmètre de votre pentest et votre surface d'attaque réelle ne nécessite pas de remplacer tout votre programme de tests de sécurité du jour au lendemain. Commencez par ces étapes concrètes :
- Exécutez un scan de découverte de surface d'attaque. Comparez ce que les outils ASM trouvent avec le périmètre de votre dernier pentest. Le delta est votre lacune de test.
- Inventoriez vos API. Cataloguez tous les endpoints, y compris les API fantômes non présentes dans les spécifications OpenAPI.
- Cartographiez vos permissions cloud. Utilisez les outils natifs cloud (AWS IAM Access Analyzer, Azure AD PIM, GCP IAM Recommender) pour identifier les politiques trop permissives.
- Élargissez le périmètre de votre prochain pentest. Ajoutez au moins une nouvelle catégorie : test API, sécurité cloud ou revue de pipeline CI/CD.
- Adoptez les tests continus. Les engagements annuels avec des périmètres statiques prendront de plus en plus de retard avec chaque année qui passe.
Les organisations qui subissent des violations via leurs API, les mauvaises configurations cloud et les pipelines CI/CD n'échouent pas parce qu'elles ne font pas de pentest. Elles échouent parce qu'elles testent le même périmètre qu'il y a cinq ans tandis que leur surface d'attaque réelle s'est étendue dix fois autour. Combler cet écart -- par un périmètre complet, une méthodologie de test moderne et une mise à l'échelle alimentée par l'IA -- est le défi déterminant des tests de sécurité d'entreprise aujourd'hui.
Questions Fréquemment Posées
Qu'est-ce que l'expansion de la surface d'attaque en pentesting ?
L'expansion de la surface d'attaque fait référence à la croissance rapide des actifs testables au-delà des applications web traditionnelles et des périmètres réseau. Les environnements modernes incluent des centaines d'endpoints API, des microservices, de l'infrastructure cloud (IAM, buckets de stockage, services de métadonnées), des pipelines CI/CD, des intégrations tierces et de l'orchestration de conteneurs. La plupart des périmètres de pentest ne couvrent que ce qui a été testé l'année précédente.
Les API doivent-elles être incluses dans les tests d'intrusion ?
Absolument. Les API sont le composant le plus sous-testé et le plus sur-estimé en termes de confiance des applications modernes. Elles exposent souvent les mêmes données et fonctionnalités que les interfaces web mais avec moins de contrôles de sécurité. Les attaques spécifiques aux API (BOLA, affectation de masse, autorisation au niveau fonctionnel défaillante) figurent régulièrement dans le OWASP API Top 10 et sont fréquemment manquées par les pentests d'applications web traditionnels.
Comment tester l'infrastructure cloud par test d'intrusion ?
Le pentesting cloud couvre l'escalade de privilèges IAM, l'exploitation des services de métadonnées, les mauvaises configurations de buckets de stockage, l'abus de confiance inter-services, les vulnérabilités des fonctions serverless et l'évasion de conteneurs. Cela nécessite des outils et une méthodologie différents des tests réseau ou d'applications web traditionnels. Le pentesting alimenté par l'IA peut automatiquement découvrir et tester les vecteurs d'attaque spécifiques au cloud.