Sécurité des applications web : votre fournisseur SaaS ne peut pas tout pour vous

Ce qu’une application web expose réellement

Une application web expose simultanément plusieurs surfaces d’attaque que la plupart des responsables non techniques n’ont pas une image complète. Il y a ce qui est visible, les pages, les formulaires, les interfaces utilisateur, et il y a ce que les utilisateurs ne voient pas mais qu’un attaquant peut cartographier en quelques minutes.

Les API et les endpoints invisibles. Une application web moderne communique via des dizaines, parfois des centaines d’interfaces de programmation. Ces API transportent des données, déclenchent des actions, interagissent avec d’autres systèmes. Chacune est un point d’entrée potentiel. Un outil comme Nmap permet lors d’une phase de reconnaissance de cartographier les services exposés et les endpoints accessibles avant même d’avoir touché à l’application.

Les intégrations tierces. Une application SaaS est rarement utilisée seule. Elle se connecte au CRM, à la messagerie, à l’annuaire, à des connecteurs tiers. 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 ce mécanisme qui fait des intégrations SaaS un vecteur de type supply chain attack : compromettre un outil périphérique pour atteindre le système central.

Le Shadow SaaS. Le Shadow IT aggrave cette problématique : des applications utilisées sans validation IT s’intègrent parfois directement avec des outils officiels via des connecteurs non supervisés, créant des surfaces d’attaque que personne ne surveille.

Les vulnérabilités applicatives web les plus fréquentes

L’OWASP (Open Worldwide Application Security Project) publie régulièrement le classement des vulnérabilités applicatives les plus rencontrées dans les applications web. Son édition 2025 s’appuie sur l’analyse de plus de 2,8 millions d’applications réelles. Voici les catégories les plus critiques, telles qu’elles se manifestent lors de nos missions de pentest applicatif.

Contrôles d’accès défaillants (Broken Access Control). C’est la première catégorie du classement OWASP depuis 2021. Un utilisateur standard accède aux données d’un autre utilisateur en modifiant un identifiant dans une URL. Un compte avec des droits limités déclenche des actions réservées aux administrateurs. Ces vulnérabilités de type IDOR (Insecure Direct Object Reference) ou escalade de privilèges constituent le vecteur le plus fréquemment trouvé dans nos audits d’élévation de privilèges.

Injections (SQL, NoSQL, commandes système). Une injection SQL permet à un attaquant d’insérer du code malveillant dans une requête envoyée à la base de données, pouvant mener à l’extraction, la modification ou la destruction de données. Ces vulnérabilités persistent dans de nombreuses applications, notamment les plus anciennes, malgré des décennies de documentation.

Failles d’authentification et de gestion de session. Mots de passe faibles, absence de MFA, tokens de session prédictibles, mécanismes de réinitialisation de mot de passe contournables : ces failles permettent à un attaquant d’usurper l’identité d’un utilisateur légitime. Les techniques comme la capture d’authentification LLMNR/NBT-NS illustrent comment des identifiants peuvent être interceptés bien avant d’atteindre l’application.

Cross-Site Scripting (XSS). L’injection de scripts malveillants dans une page web vue par d’autres utilisateurs permet de voler des cookies de session, de rediriger vers des pages de phishing ou d’exécuter des actions au nom de la victime sans qu’elle s’en apercoive.

Mauvaises configurations de sécurité. En-têtes HTTP absents ou mal configurés, pages de débogage actives en production, répertoires exposés, comptes par défaut non modifiés, éditions de logiciels non patchées : ces éléments constituent fréquemment les premiers findings d’un audit applicatif et sont les plus simples à corriger si on les identifie.

Composants vulnérables et risques supply chain. Une application web intègre en moyenne des dizaines de librairies open source et de dépendances tierces. Si l’une d’elles contient une vulnérabilité critique, l’application qui l’intègre hérite du risque. La gestion des dépendances et les mises à jour de sécurité ne sont pas optionnelles : elles font partie des exigences du Cyber Resilience Act (CRA) depuis 2024.

CSRF (Cross-Site Request Forgery) et falsification de requête côté client. Le CSRF force un utilisateur authentifié à exécuter une action à son insu : virement, changement d’email, suppression de données. L’absence du token CSRF dans les formulaires sensibles est un vecteur souvent sous-estimé.

SSRF et falsification de requête côté serveur. Ces vulnérabilités permettent à un attaquant de forcer le serveur à effectuer des requêtes vers des systèmes internes normalement inaccessibles depuis l’extérieur, ouvrant des chemins vers des services d’infrastructure non exposés publiquement.

Comment sécuriser une application web : les bonnes pratiques essentielles

1. Appliquer le principe du moindre privilège. Chaque utilisateur, chaque service et chaque composant de l’application ne doit avoir accès qu’aux ressources strictement nécessaires à sa fonction. Passer en revue régulièrement les droits attribués, désactiver les comptes inactifs, supprimer les comptes de test laissés en production.

2. Activer l’authentification multifacteur (MFA) partout. La MFA réduit drastiquement le risque de compromission d’un compte par credential stuffing ou phishing, même si le mot de passe est connu. Son absence est systématiquement signalée dans nos rapports d’audit.

3. Forcer HTTPS et configurer les en-têtes de sécurité HTTP. HSTS, Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy : ces en-têtes HTTP bloquent une large catégorie d’attaques (clickjacking, injection de contenu, XSS) avec peu d’effort de mise en oeuvre. Leur absence ou leur mauvaise configuration est un finding fréquent dans les audits de sécurité applicative.

4. Valider et assainir toutes les entrées utilisateur. Toute donnée provenant de l’utilisateur, d’une API ou d’un service tiers doit être validée côté serveur avant traitement. La validation côté client est facilement contournable et ne constitue pas une protection.

5. Gérer les dépendances et maintenir les composants à jour. Inventorier les librairies utilisées (SBOM), suivre les alertes de vulnérabilité (CVE) sur ces composants, et appliquer les mises à jour de sécurité sans délai. Les outils comme Shodan révèlent en temps réel quelles versions vulnérables sont exposées sur internet.

6. Chiffrer les données sensibles au repos et en transit. Les données personnelles, les credentials et les tokens ne doivent jamais circuler ou être stockés en clair. Utiliser des algorithmes de hachage adaptatés (bcrypt, Argon2) pour les mots de passe, et du chiffrement fort (AES-256, TLS 1.3) pour les données en transit.

7. Mettre en place une politique de logs et de détection. Journaliser les événements d’authentification, les accès aux ressources sensibles et les échecs de règles de sécurité. La surveillance des accès et des comportements anormaux permet de détecter une compromission en cours avant qu’elle ne se propage.

8. Intégrer la sécurité dans le cycle de développement (DevSecOps). Inclure des revues de code orientées sécurité, des tests SAST/DAST dans les pipelines CI/CD, et former les développeurs aux vulnérabilités les plus courantes. Notre formation sécurité applicative pour développeurs, certifiée Qualiopi, est conçue pour exactly ce besoin.

9. Réduire la surface d’attaque. Désactiver les fonctionnalités, API et services non utilisés. Supprimer les environnements de développement et de staging exposés sur internet. Fermer les ports inutiles. Chaque service exposé sans nécessité est un vecteur d’entrée supplémentaire.

10. Réaliser un test d’intrusion applicatif régulier. Les bonnes pratiques ci-dessus réduisent la surface d’attaque. Seul un test d’intrusion sur l’application web réalisé par des pentesters humains peut évaluer si ces mesures résistent à une tentative réelle de compromission, et identifier les vulnérabilités de logique métier qu’aucun scanner automatique ne peut détecter.

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é le modèle de responsabilité partagée. Le fournisseur est responsable de la sécurité de l’infrastructure. Le client est responsable de ce qu’il fait avec l’application. En 2024, le groupe ShinyHunters a compromis des dizaines d’entreprises utilisant Snowflake. La faille n’était pas dans Snowflake : elle était côté client (absence de MFA, credentials réutilisés, permissions trop larges). Les mêmes attaquants ont ciblé Ticketmaster et Authy selon la même logique.

Ce que le modèle implique côté client : configuration des rôles et des droits, activation des mécanismes de sécurité non activés par défaut (MFA, logs d’audit, chiffrement des exports), gestion du cycle de vie des comptes (désactivation des anciens collaborateurs, suppression des comptes de test), et surveillance des connexions anormales via l’annuaire d’entreprise quand les applications SaaS s’y connectent en SSO. Aucun certificat fournisseur ne couvre ces responsabilités.

Ce que les certifications fournisseurs ne garantissent pas

Mon fournisseur SaaS est certifié ISO 27001, est-ce suffisant ?

Non. Une certification ISO 27001 atteste que le fournisseur dispose d’un système de management de la sécurité et fait l’objet d’audits réguliers. C’est un signal de maturité réel. Mais cette certification couvre le périmètre du fournisseur, pas l’usage que l’organisation cliente en fait. La même logique s’applique à SOC 2, à DORA et à la quasi-totalité des certifications fournisseurs. Ce que vos équipes devraient se demander en plus : "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 et les scanners ne posent pas : est-ce que cette application, telle qu’elle est déployé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 : endpoints exposés, API, formulaires, mécanismes d’authentification, 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 en modifiant un identifiant dans une URL ? Un compte limité peut-il déclencher des actions réservées à un administrateur ? Ces vulnérabilités IDOR figurent parmi les plus fréquentes dans les audits applicatifs. Une fois un accès obtenu, l’attaquant cherche à progresser vers une élévation de privilèges.

Les vecteurs humains. Les comptes SaaS sont souvent compromis via des campagnes de phishing qui usurpent l’interface de connexion. Une mission d’ingénierie sociale menée en parallèle d’un test applicatif évalue la résistance des équipes : 9 violations sur 10 impliquent des identifiants compromis (N-able, 2025).

Les vulnérabilités de logique métier. Ces failles exploitent la façon dont l’application est censée fonctionner, pas un bug dans le code. Un processus de commande qui valide un achat sans paiement. Un workflow d’approbation contournable. Un partage de fichier qui expose les données d’un autre utilisateur. Ces vulnérabilités n’ont pas de signature CVE. Elles ne déclenchent aucune alerte dans un scanner. Seul un pentester humain qui comprend la logique métier peut les identifier.

Le rapport de mission produit ce qu’aucun questionnaire fournisseur ne peut produire : une liste de vulnérabilités réelles, classées OWASP, avec leur niveau de criticité et des recommandations de correction concrètes et priorisées.

L’idée reçue : scanner l’application suffit à la sécuriser

Les outils de scan automatique (WAF, DAST, SAST) ont une vraie valeur pour identifier rapidement des catégories connues de failles. Mais ils ont une limite structurelle : ils ne comprennent pas la logique métier. Les vulnérabilités qui exploitent la façon dont l’application est censée fonctionner n’ont pas de signature, ne déclenchent aucune alerte dans un scanner, et ne résultent pas d’un bug de code détectable automatiquement. Les informations d’identification compromises figurent dans 9 cas sur 10 de violations confirmées (N-able, 2025) : ce ne sont pas des failles de code, c’est une chaîne humaine et technique que seule une évaluation manuelle permet de reconstituer.

Un scanner est utile pour la surveillance continue de patterns connus. Il ne remplace pas un regard humain sur l’application dans son contexte réel. C’est la différence entre vérifier que le code ne contient pas de patterns dangereux connus, et vérifier que l’application ne peut pas être détournée par quelqu’un qui cherche activement à le faire.