Tests de sécurité des applications web : le guide complet

Si votre application web gère des connexions, des paiements ou des données clients, quelqu’un finira par vous demander de prouver qu’elle est sécurisée : le questionnaire de sécurité d’un acheteur grand compte, un auditeur, ou votre propre conseil d’administration après qu’une faille dans votre secteur a fait la une. Une réponse crédible commence par savoir en quoi consistent réellement les tests de sécurité des applications web, et quelles parties vous payez lorsque vous les menez en interne ou faites appel à des services de tests de sécurité.

Les tests de sécurité des applications web identifient les failles exploitables d’une application web avant que des attaquants ne le fassent. Ils combinent quatre approches : l’analyse statique du code source (SAST), les tests dynamiques de l’application en fonctionnement depuis l’extérieur (DAST), les tests instrumentés depuis l’intérieur de l’application à l’exécution (IAST) et les tests d’intrusion manuels. Chacune détecte une catégorie de failles différente, c’est pourquoi un programme efficace en utilise plusieurs.

La principale décision de coût porte sur l’ordre de mise en place. Une fois configurés, les scans automatisés SAST et DAST coûtent peu par exécution et peuvent tourner à chaque build ou chaque nuit. Un test d’intrusion manuel d’une application web de taille moyenne demande généralement une à trois semaines de travail d’un spécialiste, ce qui en fait la couche la plus coûteuse, celle qu’il faut planifier avec soin. Se tromper d’ordre revient généralement à payer des pentesteurs pour trouver des problèmes qu’un scanner gratuit aurait détectés.

Ci-dessous : ce que fait chaque approche, ses limites, et quand vous avez besoin de laquelle.

Les 4 approches de test : SAST, DAST, IAST et tests d'intrusion

Les quatre approches diffèrent par ce qu’elles examinent et par le moment où elles interviennent. Le SAST lit le code avant sa mise en production, le DAST et l’IAST testent l’application pendant son exécution, et les tests d’intrusion la confrontent à un attaquant humain. Chacune a des angles morts que les autres couvrent, c’est pourquoi les programmes matures utilisent les quatre à différents moments du cycle de livraison.

Tests statiques de sécurité des applications (SAST)

Le SAST analyse le code source, le bytecode ou les binaires sans exécuter l’application. Il suit le flux des données depuis les entrées utilisateur jusqu’aux opérations sensibles et signale des schémas comme une entrée non assainie qui atteint une requête de base de données, des secrets codés en dur ou une cryptographie faible. Il peut tourner dans l’IDE d’un développeur ou sur chaque pull request, et il indique le fichier et la ligne exacts.

Sa limite, c’est le contexte. Le SAST ne voit pas comment l’application est configurée ni déployée, et il signale souvent des chemins de code inaccessibles en pratique : le premier scan d’une base de code existante produit donc généralement une longue liste que quelqu’un doit trier.

L’analyse de la composition logicielle (SCA) accompagne généralement le SAST et vérifie les bibliothèques tierces à la recherche de vulnérabilités connues, le risque qui se cache derrière les composants vulnérables et obsolètes.

Tests dynamiques de sécurité des applications (DAST)

Le DAST teste l’application en fonctionnement depuis l’extérieur, comme le ferait un attaquant, sans accès au code. Un scanner parcourt l’application, envoie des requêtes forgées à chaque champ de saisie qu’il trouve et analyse les réponses à la recherche de signes d’injection, de cross-site scripting (XSS), d’en-têtes de sécurité manquants, de fichiers exposés et de serveurs mal configurés.

Le DAST détecte les problèmes qui n’existent qu’une fois l’application déployée : configuration du serveur et de TLS, attributs des cookies, pages d’erreur qui divulguent des traces de pile. Il est moins efficace sur tout ce qu’un crawler ne peut pas atteindre, comme les pages protégées par une authentification en plusieurs étapes ou les routes d’une application monopage qui n’apparaissent qu’après l’exécution du JavaScript. Quand il trouve un problème, il indique une URL, et les développeurs doivent encore localiser le code.

Tests interactifs de sécurité des applications (IAST)

L’IAST place un agent à l’intérieur de l’application en fonctionnement, dans le runtime du langage ou le serveur d’applications, et observe ce que fait le code pendant que l’application est sollicitée. Quand une requête de test fait passer une entrée dans une requête SQL ou un chemin de fichier, l’agent voit à la fois la requête et la ligne de code exacte qui l’a traitée.

Il combine ainsi la vue à l’exécution du DAST et la précision au niveau du code du SAST, généralement avec moins de faux positifs que l’un ou l’autre. Le revers, c’est la couverture : l’IAST n’analyse que les chemins de code réellement exécutés, sa valeur dépend donc de la qualité des tests fonctionnels et de régression qui pilotent l’application. Il exige aussi un agent compatible avec votre langage et votre framework, et il ajoute une certaine surcharge à l’environnement de test dans lequel il tourne.

Tests d'intrusion manuels

Un test d’intrusion, c’est un spécialiste de la sécurité qui tente activement de pénétrer dans l’application avec les objectifs d’un véritable attaquant : lire les données d’un autre client, transformer un compte ordinaire en compte administrateur ou contourner une étape de paiement. Les testeurs utilisent des scanners pour la couverture, puis consacrent l’essentiel de leur temps à ce que les outils ne savent pas évaluer, comme enchaîner deux vulnérabilités de faible gravité pour en obtenir une grave, ou détourner un workflow techniquement valide mais qui n’aurait jamais dû être autorisé.

Des quatre approches, le test d’intrusion est celle qui détecte de manière fiable les failles d’autorisation et les abus de logique métier, et il produit des preuves qu’un acheteur ou un auditeur acceptera. C’est aussi un instantané à un moment donné et la couche la plus coûteuse par vulnérabilité trouvée. Selon ce que le testeur sait au départ, un test d’intrusion se déroule en boîte noire, grise ou blanche, et c’est ainsi que QAwerk structure ses services de tests d’intrusion.

SAST, DAST, IAST et tests d'intrusion en un coup d'œil

Comment ces approches se complètent

Le SAST détecte les problèmes au plus tôt, quand la correction se résume à modifier une ligne dans une branche non fusionnée, ce qui en fait la couche la moins coûteuse à traiter. Le SAST ne peut pas vous dire si une ligne signalée est atteignable, ni si le serveur déployé est configuré de manière sûre.

Le DAST et l’IAST repèrent ce qui n’apparaît qu’à l’exécution. Le DAST vérifie l’application telle qu’elle est déployée, y compris le serveur web, les paramètres TLS et les en-têtes de réponse. L’IAST confirme quels problèmes de flux de données sont réels en les observant se produire, c’est pourquoi il s’associe bien à une suite de régression automatisée existante : les tests qui vérifient déjà les fonctionnalités se mettent aussi à vérifier la sécurité.

Les tests d’intrusion manuels couvrent la catégorie de failles que l’automatisation gère le moins bien. Un scanner peut confirmer qu’un endpoint exige une connexion. Il ne peut pas voir qu’un client connecté peut modifier l’ID d’une commande dans l’URL et consulter la facture de quelqu’un d’autre. Ce type de contrôle d’accès défaillant occupe la première place du classement OWASP Top 10:2025, et pour le trouver, il faut une personne qui comprend ce que l’application est censée autoriser. Pour voir à quoi ressemble la couche manuelle, domaine par domaine, consultez notre checklist de tests d’intrusion d’applications web.

La méthodologie de test OWASP

L’Open Worldwide Application Security Project (OWASP) publie le Web Security Testing Guide (WSTG), la référence la plus citée sur la manière de tester la sécurité d’une application web. Sa version stable actuelle, la 4.2, organise les tests actifs en 12 catégories :

• Collecte d’informations
• Tests de gestion de la configuration et du déploiement
• Tests de gestion des identités
• Tests d’authentification
• Tests d’autorisation
• Tests de gestion des sessions
• Tests de validation des entrées
• Tests de gestion des erreurs
• Tests de cryptographie faible
• Tests de logique métier
• Tests côté client
• Tests d’API

Chaque catégorie contient des cas de test numérotés. Les tests de gestion des sessions, par exemple, couvrent les attributs des cookies, la fixation de session, la falsification de requêtes intersites (cross-site request forgery), le comportement à la déconnexion et l’expiration de session. Les rapports de tests d’intrusion professionnels citent souvent ces identifiants (WSTG-SESS-05 correspond au test de falsification de requêtes intersites) afin que chaque vulnérabilité renvoie à une procédure documentée.

Voici une correspondance réaliste entre les catégories du WSTG et les quatre approches :

• Collecte d’informations, configuration et tests côté client : en grande partie automatisables avec le DAST, une personne examinant ce que signale le scanner.
• Validation des entrées et cryptographie faible : bien couvertes par le SAST dans le code et par le DAST ou l’IAST à l’exécution.
• Authentification et gestion des sessions : partiellement automatisables, mais le verrouillage de compte, la réinitialisation du mot de passe et l’expiration de session exigent un testeur qui parcourt les flux étape par étape.
• Autorisation et logique métier : presque entièrement du ressort des tests d’intrusion manuels.

Son standard complémentaire, l’OWASP Application Security Verification Standard (ASVS), définit des exigences de sécurité selon trois niveaux de rigueur, ce qui vous aide à déterminer jusqu’où les tests doivent aller pour votre application.

Mettre en place un programme de tests de sécurité des applications web

Un programme de tests suit le cycle de vie du développement logiciel (SDLC). Le Secure Software Development Framework, SP 800-218 du National Institute of Standards and Technology (NIST) américain distingue deux pratiques : la revue du code lisible par l’humain à la recherche de vulnérabilités (pratique PW.7) et le test du code exécutable (pratique PW.8).

Ne bloquez les fusions que sur les résultats SAST de gravité élevée, sinon les développeurs apprennent à ignorer l’outil, et refaites un test après chaque test d’intrusion, car une correction non vérifiée reste une vulnérabilité ouverte.

Côté fréquence, la plupart des équipes commencent par un test d’intrusion annuel suivi d’un retest après correction. Pour les applications qui stockent, traitent ou transmettent des données de cartes bancaires, la norme PCI DSS impose un test d’intrusion au moins une fois tous les 12 mois et après tout changement important. Les produits fintech, healthtech ou tout ce qui conserve des pièces d’identité sont généralement testés plus souvent. Notre guide sur la fréquence des tests d’intrusion explique comment définir ce rythme selon votre profil de risque.

Si vous partez de zéro, cet ordre offre la meilleure couverture pour le moindre coût :

1. Activez le SAST et l’analyse des dépendances dans le dépôt.
2. Ajoutez un scan DAST sur votre environnement de staging.
3. Planifiez un test d’intrusion ciblé avant votre prochaine release importante ou votre prochaine revue de sécurité.
4. Ajoutez l’IAST une fois que vous disposez d’une suite de régression automatisée qui vaut la peine d’être instrumentée.

Si vous devez défendre en interne le budget de cette troisième étape, voici pourquoi les tests d’intrusion sont importants pour un produit à votre stade.

Quand une configuration plus légère suffit

Toutes les applications n’ont pas besoin des quatre couches. Un site marketing sans connexion, sans données clients stockées et avec un seul formulaire de contact a besoin d’un scan DAST, d’une configuration serveur renforcée et de mises à jour régulières des dépendances, et un test d’intrusion complet y offre un mauvais rapport qualité-prix. Mieux vaut reporter l’IAST jusqu’à disposer d’une solide couverture de tests automatisés, car un agent qui observe trois smoke tests n’analyse presque rien. Un test d’intrusion sur une application que personne n’a encore scannée consacre des heures coûteuses à des vulnérabilités qu’un outil gratuit aurait signalées.

La combinaison complète justifie son coût pour toute application comportant plusieurs rôles utilisateurs, des paiements, des données personnelles ou réglementées, ou des clients grands comptes qui envoient des questionnaires de sécurité.

Comment QAwerk mène les tests de sécurité des applications web

Chez QAwerk, les tests de sécurité sont assurés par la même équipe que les tests fonctionnels et les tests de régression. Les ingénieurs QA qui construisent la suite de régression savent quels parcours comptent, les exécutions DAST et IAST couvrent donc les chemins qu’empruntent les vrais utilisateurs, et les pentesteurs démarrent avec les rôles et les règles métier déjà cartographiés. Un responsable de la validation reproduit chaque vulnérabilité et la documente avec les étapes et les preuves, pour que les développeurs puissent la traiter au sprint suivant.

Nous intervenons à n’importe quel stade du produit, d’une application en pré-lancement qui a besoin de son premier test d’intrusion à un produit en production face à sa première revue de sécurité d’un client grand compte. Nos missions couvrent la revue de code SAST et les tests d’intrusion en boîte noire, grise ou blanche, facturés sur la base d’estimations Time & Material avec une fourchette réaliste et une fourchette pessimiste pour chaque tâche. QAwerk a réalisé des tests d’intrusion pour des produits fintech et de vérification d’identité, où l’autorisation et la gestion des sessions font l’objet de l’examen le plus attentif.

Combiner tests statiques, dynamiques et manuels

Aucune approche de test ne détecte tout à elle seule. Le SAST écarte tôt le code défaillant, le DAST et l’IAST montrent ce qui se passe à l’exécution, et les tests d’intrusion manuels trouvent les failles d’accès et de logique que l’automatisation laisse passer. Un vrai programme de sécurité des applications web exécute chacun d’eux à son propre moment du SDLC. Si vous souhaitez qu’une seule équipe le planifie et le mène, parlez-nous de la sécurité de votre application web via nos services de tests d’applications web.

FAQ

Quelle est la différence entre SAST et DAST ?

Le SAST analyse le code source sans l’exécuter et indique la ligne exacte d’une faille : il intervient donc tôt, à chaque commit. Le DAST teste l’application en fonctionnement depuis l’extérieur et détecte les problèmes de configuration et d’exécution : il nécessite donc un build déployé. Ils détectent des problèmes différents, et la plupart des équipes utilisent les deux.

L'IAST remplace-t-il le DAST ?

L’IAST est plus précis, mais il ne voit que les chemins de code exécutés par vos tests et nécessite un agent compatible avec votre stack. Le DAST vérifie toujours le serveur web déployé, les paramètres TLS et les en-têtes, les deux fonctionnent donc mieux ensemble.

Les scanners automatisés peuvent-ils remplacer un test d'intrusion ?

Non. Les scanners sont efficaces sur les schémas connus comme les injections et les mauvaises configurations. Ils ne peuvent pas juger si un utilisateur devrait être autorisé à voir un enregistrement ou à sauter une étape d’un workflow, et c’est précisément là que se logent le contrôle d’accès défaillant et les failles de logique métier. Pour les trouver, il faut un testeur humain.

À quelle fréquence faut-il tester la sécurité d'une application web ?

Lancez les scans SAST et de dépendances à chaque modification, le DAST au moins une fois par release, et un test d’intrusion manuel au moins une fois par an et après tout changement important. Les applications qui traitent des paiements, des données de santé ou des pièces d’identité ont généralement besoin de tests d’intrusion plus fréquents.

Qu'est-ce que la méthodologie de test OWASP ?

C’est l’approche définie dans le Web Security Testing Guide de l’OWASP, qui regroupe les tests de sécurité des applications web en 12 catégories, de la collecte d’informations et des tests d’authentification à la gestion des sessions, la validation des entrées et la logique métier. Les testeurs citent ses identifiants de test dans leurs rapports.