TL;DR
Selon le rapport Verizon DBIR 2025, les vulnérabilités applicatives web représentent 42 % des vecteurs de violation de données. En 2024, les brèches chez Snowflake, Ticketmaster et Authy ont exposé des dizaines de millions de données sensibles, non pas à cause d’une faille dans l’infrastructure du fournisseur, mais à cause d’erreurs de configuration côté client : absence de MFA, gestion des accès insuffisante, credentials réutilisés.
C’est la règle du SaaS que beaucoup d’organisations découvrent trop tard. La sécurité d’une application web SaaS n’est jamais entièrement déléguée au fournisseur.
Votre fournisseur SaaS est certifié et votre contrat signé. Mais qui a vérifié que votre configuration, vos accès et vos intégrations sont réellement sécurisés ? Quand une entreprise adopte une application SaaS, elle a tendance à considérer la sécurité comme une caractéristique du produit, quelque chose dont le fournisseur s’occupe. Cette lecture n’est pas irrationnelle. Elle est même encouragée par les certifications affichées et les pages de confiance que les éditeurs soignent avec attention.
Elle est pourtant incomplète, et cette incomplétude est précisément ce que les groupes de cybercriminels les plus actifs exploitent aujourd’hui. La sécurité d’une application web, qu’elle soit développée en interne ou achetée en mode SaaS, est le produit d’une chaîne de décisions. Certaines appartiennent au fournisseur. D’autres appartiennent à l’organisation qui l’utilise. Et c’est presque toujours dans l’espace entre les deux que les brèches se produisent.
Ce qu’une application web expose réellement
Une application web expose plusieurs surfaces d’attaque simultanément, et la plupart des responsables non techniques n’en ont pas une image complète. En 2025, 90,9 % des organisations ont été touchées par une attaque ciblant une application web ou mobile (CyberEdge Group, 2025). Ce chiffre n’est pas celui d’un secteur particulier : il décrit une réalité transversale à toutes les tailles d’organisations.
Ce qui est visible : les pages et formulaires. C’est la partie de l’application que les utilisateurs voient et manipulent. Elle contient souvent des failles classiques, des zones de saisie qui n’ont jamais été testées contre des entrées malveillantes, des mécanismes d’authentification qui ne vérifient pas correctement qui accède à quoi. Ces vulnérabilités correspondent aux catégories documentées par l’OWASP (Open Worldwide Application Security Project), dont la dernière édition publiée en novembre 2025 s’appuie sur l’analyse de plus de 2,8 millions d’applications réelles.
Ce qui est invisible pour l’utilisateur mais accessible pour un attaquant : les API. Une application web moderne communique en permanence via des interfaces de programmation, souvent des dizaines, parfois des centaines. Ces API transportent des données, déclenchent des actions, interagissent avec d’autres systèmes. Chacune est un point d’entrée potentiel si elle n’est pas conçue avec les bonnes vérifications d’accès. Un outil comme Nmap permet lors d’une première phase de reconnaissance de cartographier les services exposés, avant d’aller plus loin dans l’analyse applicative elle-même.
Les intégrations tierces. Une application SaaS est rarement utilisée seule. Elle se connecte au CRM, à la messagerie, à l’annuaire d’entreprise, à des outils tiers via des connecteurs. Chacune de ces connexions est un maillon dans une chaîne, et la solidité de la chaîne dépend de son maillon le plus faible. C’est précisément ce mécanisme qui fait des intégrations SaaS un vecteur d’attaque de type supply chain : compromettre un outil périphérique pour atteindre le système central. Par ailleurs, le Shadow IT aggrave cette problématique : des applications SaaS utilisées sans validation IT s’intègrent parfois directement avec des outils officiels via des connecteurs non supervisés.
Le modèle de responsabilité partagée, ce que votre contrat SaaS ne dit pas clairement
Tous les grands fournisseurs de cloud et de SaaS ont formalisé ce que l’industrie appelle le modèle de responsabilité partagée. L’idée est simple : le fournisseur est responsable de la sécurité de l’infrastructure sur laquelle l’application tourne. Le client est responsable de ce qu’il fait avec l’application.
En 2024, le groupe ShinyHunters a compromis des dizaines d’entreprises qui utilisaient la plateforme cloud Snowflake. La faille n’était pas dans Snowflake lui-même. Elle était côté client : des accès configurés sans authentification multifacteur, des credentials réutilisés depuis d’autres services compromis, une gestion des permissions trop permissive. Les mêmes attaquants ont ciblé Ticketmaster et Authy selon la même logique. Snowflake n’avait pas failli à ses obligations. Les clients avaient omis de faire leur part.
Ce que le modèle de responsabilité partagée implique concrètement côté client, c’est la configuration des droits d’accès et des rôles utilisateurs, l’activation des mécanismes de sécurité proposés mais non activés par défaut (MFA, chiffrement des exports, logs d’audit), la gestion du cycle de vie des comptes (désactivation des accès des anciens collaborateurs, suppression des comptes de test), et la surveillance des connexions et des comportements anormaux via l’annuaire d’entreprise quand les applications SaaS s’y connectent en SSO.
Aucun certificat du fournisseur ne couvre ces responsabilités. Elles appartiennent entièrement à l’organisation cliente.
Ce que les certifications fournisseurs ne garantissent pas
Mon fournisseur SaaS est certifié ISO 27001, est-ce suffisant ?
Non. Et c’est probablement le malentendu le plus répandu dans la façon dont les organisations évaluent la sécurité de leurs applications SaaS. Une certification ISO 27001 atteste que le fournisseur dispose d’un système de management de la sécurité de l’information et qu’il fait l’objet d’audits réguliers. C’est un signal de maturité réel, et c’est pertinent. Mais cette certification couvre le périmètre du fournisseur, pas l’usage que l’organisation cliente en fait.
La campagne ShinyHunters 2024 l’a illustré avec précision : les attaques n’ont pas exploité de vulnérabilités au niveau des fournisseurs, mais des lacunes de sécurité chez les clients SaaS, notamment l’absence de MFA et une gestion insuffisante des listes d’accès. La même logique s’applique à SOC 2, à DORA, et à la quasi-totalité des certifications de fournisseurs. Elles valident que le fournisseur a mis en place certaines pratiques. Elles ne valident pas que la configuration que vous avez déployée dans votre instance est sécurisée.
Ce que vos équipes devraient se demander ne se limite pas à "est-ce que notre fournisseur est certifié ?" mais aussi "est-ce que notre configuration de cet outil a fait l’objet d’une vérification indépendante ?"
Ce qu’un test d’intrusion applicatif révèle concrètement
Un test d’intrusion sur une application web répond à une question que les certifications fournisseurs ne posent pas : est-ce que cette application, telle qu’elle est déployée et configurée dans notre contexte, peut être compromise par un attaquant qui cherche activement à le faire ?
La phase de reconnaissance. Nos pentesters cartographient la surface d’attaque réelle : les endpoints exposés, les API, les formulaires, les mécanismes d’authentification, les intégrations tierces. À cette étape apparaissent régulièrement des fonctionnalités oubliées, des sous-domaines de test jamais supprimés, des API héritées exposées sans nécessité.
Les contrôles d’accès. Un utilisateur standard peut-il accéder aux données d’un autre utilisateur en modifiant un identifiant dans une URL ? Un compte avec des droits limités peut-il déclencher des actions réservées à un administrateur ? Ces vulnérabilités de type IDOR (Insecure Direct Object Reference) figurent systématiquement parmi les plus fréquentes dans les audits applicatifs. Une fois un accès obtenu, l’attaquant cherche généralement à progresser vers une élévation de privilèges qui lui donne accès à des fonctions d’administration ou à des données plus sensibles.
Les vecteurs humains liés à l’application. Les comptes SaaS sont souvent compromis non pas par une faille technique dans l’application elle-même, mais via des campagnes de phishing qui usurpent l’interface de connexion de l’outil. Une mission d’ingénierie sociale menée en parallèle d’un test applicatif permet d’évaluer la résistance des équipes face à ces tentatives ciblées, qui restent le premier vecteur de compromission des comptes SaaS selon le rapport N-able 2025 (9 violations sur 10 impliquent des identifiants).
Le rapport de mission. Il produit ce qu’aucun questionnaire fournisseur ne peut produire : une liste de vulnérabilités réelles, dans l’application telle qu’elle existe aujourd’hui, avec leur niveau de criticité et des recommandations de correction concrètes, classifiables selon les catégories OWASP pour faciliter la priorisation des corrections.
Si vos équipes développent en interne des applications web ou des connecteurs avec vos outils SaaS, notre formation à la sécurité applicative pour développeurs, certifiée Qualiopi, leur permet de comprendre concrètement comment les failles qu’un pentester cherche se créent dans le code, avant qu’un audit externe ne les révèle.
L’idée reçue à corriger : scanner l’application suffit à la sécuriser
Les outils de scan automatique de vulnérabilités (WAF, scanners DAST, outils de test statique) ont une vraie valeur. Ils identifient rapidement des catégories connues de failles dans des patterns de code courants. Mais ils ont une limite structurelle : ils ne comprennent pas la logique métier de l’application.
Une vulnérabilité de logique métier exploite la façon dont l’application est censée fonctionner, pas un bug dans le code. Un processus de commande qui permet de valider un achat sans effectuer le paiement. Un mécanisme de partage qui expose les fichiers d’un autre utilisateur si l’on connaît le bon identifiant. Un workflow d’approbation contournable en changeant l’ordre des étapes. Ces vulnérabilités n’ont pas de signature connue. Elles ne déclenchent pas d’alerte dans un scanner. La seule façon de les identifier est qu’un être humain comprenne ce que l’application est censée faire et explore méthodiquement ce qui se passe quand on s’en écarte.
Les informations d’identification compromises figurent dans 9 cas sur 10 de violations confirmées d’applications web (N-able, 2025). Ces compromissions ne résultent pas d’une faille de code détectable automatiquement. Elles résultent d’une chaîne humaine et technique que seule une évaluation manuelle permet de reconstituer complètement.
Un outil de scan est utile pour maintenir une vigilance continue sur des patterns connus. Il ne remplace pas un regard humain indépendant sur l’application dans son contexte réel. C’est la différence entre vérifier que le code ne contient pas de patterns connus comme dangereux, et vérifier que l’application ne peut pas être détournée par quelqu’un qui cherche activement à le faire.
Votre application web ou SaaS a-t-elle été testée comme un attaquant la testerait ?
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
La sécurité réseau protège les flux qui circulent entre les systèmes, les ports ouverts, les pare-feux, le chiffrement des communications. La sécurité applicative s’intéresse à ce que fait l’application elle-même une fois la connexion établie : est-ce qu’elle vérifie correctement les droits d’accès ? Est-ce qu’elle traite les données saisies de façon sécurisée ? Est-ce que ses API exposent plus d’informations qu’elles ne devraient ? Les deux sont nécessaires et complémentaires.
L’hébergement chez un fournisseur cloud reconnu protège l’infrastructure physique et la disponibilité du service. Il ne protège pas contre les erreurs de configuration de votre instance, les accès mal gérés, les API mal configurées ou les vulnérabilités dans le code de l’application elle-même. C’est le modèle de responsabilité partagée : le fournisseur sécurise ce qu’il maîtrise, vous sécurisez ce que vous maîtrisez.
Pour toute organisation qui exploite une application web accessible depuis internet, qu’elle soit développée en interne, achetée en SaaS ou les deux. Cela concerne les boutiques e-commerce, les portails client, les outils métier exposés sur internet, les API qui alimentent des applications mobiles, et les extranet B2B. La taille de l’organisation importe moins que l’exposition et la nature des données traitées.
Non. Un scanner détecte des catégories connues de failles dans des patterns de code courants. Un test d’intrusion applicatif inclut une analyse manuelle de la logique métier, des contrôles d’accès et des flux de données que les outils automatiques ne comprennent pas. Les deux sont complémentaires : le scanner pour la surveillance continue sur des patterns connus, le pentest pour l’évaluation indépendante dans le contexte réel.
Un pentest applicatif est une mission encadrée et confidentielle, avec un périmètre défini, un rapport livré sous NDA et un calendrier maîtrisé. Il permet de documenter l’ensemble des vulnérabilités trouvées dans un délai donné. Un bug bounty ouvre la recherche de vulnérabilités à une communauté de chercheurs externes sur la durée, avec une rémunération à la découverte. Les deux ne s’excluent pas, mais le pentest reste plus adapté lorsqu’une organisation a besoin d’une évaluation complète et confidentielle dans un cadre contractuel précis.
Le Shadow IT désigne les applications utilisées sans validation du service informatique. Dans le contexte SaaS, cela signifie des outils déployés sans évaluation de sécurité, souvent connectés via des intégrations non contrôlées à d’autres systèmes de l’organisation. Ce sont des surfaces d’attaque que personne ne surveille, parce que personne ne sait officiellement qu’elles existent.
La détection d’une compromission applicative nécessite une supervision active des journaux d’accès et des comportements anormaux. Le monitoring Active Directory couvre partiellement cet enjeu côté authentification et accès SSO. Pour les applications web elles-mêmes, une surveillance des anomalies de trafic et des accès inhabituels est nécessaire. En l’absence de supervision active, une compromission peut passer inaperçue pendant des mois.
Votre fournisseur SaaS est certifié et votre contrat signé. Mais qui a vérifié que votre configuration, vos accès et vos intégrations sont réellement sécurisés ? Ce que les certifications ne couvrent pas, et ce que les scanners automatiques ratent.
