Bienvenue sur notre blog.

Entrons dans l'attaque de la chaîne d'approvisionnement de tj-actions/changed-files. Lisez la suite pour savoir ce qu'il faut faire, ce qui s'est passé et plus d'informations.

TL;DR

- Le tj-actions/changed-files GitHub Action, qui est actuellement utilisé dans plus de 23 000 dépôts, a été compromis, laissant échapper des secrets par le biais de journaux de flux de travail et ayant un impact sur des milliers de pipelines de CI.

- Toutes les versions étiquetées ont été modifiées, ce qui rend l'épinglage basé sur les étiquettes peu sûr. Les dépôts publics sont les plus exposés, mais les dépôts privés devraient également vérifier leur exposition.

- Les mesures immédiates consistent à identifier les flux de travail concernés, à supprimer toutes les références à l'action compromise, à assurer la rotation des secrets et à vérifier les journaux pour y déceler toute activité suspecte.

Réponse d'Aikido : Nous avons publié une nouvelle règle SAST qui signale toute utilisation avec une sévérité critique (Score 100). Aikido peut automatiquement épingler vos actions Github pour éviter ce type d'exploit à l'avenir.

Tout d'abord, que faire ?

Vérifiez si vous êtes concerné par la j-actions/changed-files attaque de la chaîne d'approvisionnement :

A) Rechercher tj-actions dans votre base de données

B) Utilisez cette requête Github pour trouver des références à l'action GitHub concernée dans les dépôts de votre organisation (remplacez [votre-org] par le nom de votre organisation).

Cessez d'utiliser tj-actions/changed-files dès que possible et supprimez toutes les références à l'action compromise.

Faites tourner les secrets des pipelines concernés et vérifiez les journaux de vos services (tiers) pour détecter toute utilisation suspecte des jetons exposés ; concentrez-vous d'abord sur les dépôts dont les journaux d'exécution de CI sont accessibles au public.

Passons à l'attaque : Que s'est-il passé ?

Un incident de sécurité impliquant le tj-actions/changed-files L'action GitHub a été identifiée à la mi-mars 2025. Les attaquants ont introduit un code malveillant qui expose les secrets CI/CD via les journaux de flux de travail. D'abord rapporté par Step Security, l'incident a été assigné à CVE-2025-30066.

Bien qu'il y ait un manque de clarté sur ce qui s'est passé et comment le code a été poussé, la plupart des rapports indiquent que l'attaquant a compromis un jeton d'accès personnel GitHub (PAT) lié au compte tj-actions-bot, ce qui a permis à l'attaquant d'apporter des modifications non autorisées, d'injecter du code malveillant et de manipuler les balises de version.

Chronologie des événements :

Avant le 14 mars 2025 : Le code malveillant a commencé à avoir un impact sur les dépôts affectés, provoquant des fuites de secrets dans les journaux publics.

14 mars 2025 : Des chercheurs en sécurité identifient la compromission et sensibilisent l'opinion publique.

15 mars 2025 : Le script malveillant hébergé sur GitHub Gist a été supprimé. Le dépôt compromis a été brièvement mis hors ligne pour annuler les modifications malveillantes, puis restauré sans les modifications nuisibles.

15 mars 2025 : Le repo est de nouveau en ligne avec une déclaration sur l'attaque ; le mainteneur a également commenté l'attaque.

Bien que la menace immédiate ait été résolue, les versions en cache de l'action compromise peuvent encore présenter un risque. Il est nécessaire de prendre des mesures d'atténuation proactives pour sécuriser les informations d'identification sensibles.

Quel est l'impact de l'attaque tj-actions/changed-files ?

Dépôts utilisant des tj-actions/changed-filesLes entreprises, en particulier les entreprises publiques, risquent de divulguer les secrets utilisés dans leurs pipelines. Ces secrets ont été révélés dans les journaux de flux de travail par le code malveillant de l'acteur de la menace. Bien qu'aucune exfiltration de données externes n'ait été confirmée, des acteurs malveillants ont pu accéder aux journaux des dépôts publics. Les dépôts privés sont moins concernés, mais ils doivent néanmoins évaluer leur exposition et remplacer les secrets s'ils sont touchés.

Dépôts publics : Risque élevé en raison de l'exposition publique de journaux de flux de travail contenant des secrets.

Dépôts privés : Risque plus faible, mais le fait que des secrets actifs soient exposés dans vos journaux de flux de travail constitue toujours un risque important.

Utilisateurs d'actions mises en cache : Les flux de travail qui ont mis en cache l'action compromise peuvent continuer à présenter un risque jusqu'à ce que les caches soient purgés.

Comment l'aïkido peut-il aider ?

Nous avons publié un nouvelle règle SAST qui signale tout tj-actions/changed-files utilisation avec gravité critique (Score 100). Si vous utilisez déjà Aikido, vous êtes couvert. Si vous n'avez pas de compte Aikido, vous pouvez vous connecter et scanner votre installation en quelques secondes.

Au-delà de cette attaque, Aikido épingle automatiquement vos actions Github afin d'éviter ce genre d'exploit à l'avenir.

Et notre flux propriétaire de menaces de logiciels malveillants - Aikido Intel - détecte les logiciels malveillants dans les 3 minutes suivant leur publication sur npm, pypi, et sera bientôt étendu aux actions Github.

Nous facilitons l'accès à votre chaîne d'approvisionnement en logiciels et vous avertissons au plus tôt des nouveaux risques et des nouvelles attaques.

En savoir plus sur l'attaque :

- Une analyse de "Comprendre et recréer l'attaque de la chaîne d'approvisionnement tj-actions/changed-files" par James Berthoty, analyste chez Latio. James vous montre également comment recréer l'attaque dans votre propre environnement pour tester votre capteur (attention).

- Step Security, qui a été le premier à signaler l'attaque, a publié une analyse de l'enquête, "Harden-Runner detection : tj-actions/changed-files action is compromised" (Détection Harden-Runner : l'action tj-actions/changed-files est compromise)

- Voir CVE-2023-51664

Pourquoi êtes-vous ici ?

Vous voulez connaître la vraie réponse à deux questions sur la sécurité de Docker :

Docker est-il sûr pour une utilisation en production ?

‍Ouiet non. Docker utilise un modèle de sécurité qui repose sur les espaces de noms et l'isolation des ressources, ce qui rend les processus à l'intérieur plus sûrs contre les attaques spécifiques que l'exécution de vos applications directement à partir d'une VM cloud ou d'un système bare metal.Malgré cette couche, il existe encore de nombreux moyens pour les attaquants d'accéder à votre conteneur, ce qui leur permet de lire des informations confidentielles, d'exécuter des attaques par déni de service (DoS) ou même d'obtenir un accès racine au système hôte.

Comment puis-je améliorer ma sécurité Docker (d'une manière pas trop douloureuse) ?

‍Nousallons vous présenter les vulnérabilités les plus courantes et les plus graves de Docker, en passant outre les recommandations de base que vous trouverez partout sur Google, comme l'utilisation d'images officielles et la mise à jour de votre hôte.Au lieu de cela, nous vous conduirons directement vers les nouvelles options de Docker et les lignes de Dockerfile qui rendront votre nouveau déploiement de conteneurs Docker par défaut beaucoup plus sûr que jamais.

La liste de contrôle de sécurité de Docker (no-BS)

Rendre les systèmes de fichiers du conteneur accessibles en lecture seule

Que gagnez-vous ?

Vous empêchez un pirate de modifier l'environnement d'exécution de votre conteneur Docker, ce qui pourrait lui permettre de recueillir des informations utiles sur votre infrastructure, de collecter des données utilisateur ou de mener directement une attaque DOS ou par ransomware.

Comment le régler ?

Vous avez deux options, soit au moment de l'exécution, soit dans votre configuration Docker Compose.

Au moment de l'exécution : docker run --read-only votre-app:v1.0.1

Dans votre fichier Docker Compose :

services :
webapp :
image : your-app:v1.0.1read_only : true
...

Escalade des privilèges de verrouillage

Que gagnez-vous ?

Vous empêchez votre conteneur Docker - ou un attaquant qui s'amuse à l'intérieur dudit conteneur - d'activer de nouveaux privilèges, même au niveau racine, avec setuid ou setgid. Avec un accès plus permissif à votre conteneur, un attaquant pourrait accéder à des informations d'identification sous la forme de mots de passe ou de clés pour des parties connectées de votre déploiement, comme une base de données.

Comment le régler ?

Encore une fois, au moment de l'exécution ou dans votre configuration Docker Compose.

Au moment de l'exécution : docker run --security-opt=no-new-privileges your-app:v1.0.1

Dans votre fichier Docker Compose :

les services : 
	webapp :    
		image : your-app:v1.0.1    
		security_opt:      
			- no-new-privileges:true    
...

Isolez vos réseaux de conteneurs à conteneurs

Que gagnez-vous ?

Par défaut, Docker laisse tous les conteneurs communiquer via le réseau docker0, ce qui peut permettre à un attaquant de se déplacer latéralement d'un conteneur compromis à un autre. Si vous avez des services discrets A et B dans des conteneurs Y et ZSi les deux parties n'ont pas besoin de communiquer directement, l'isolation de leurs réseaux offre la même expérience à l'utilisateur final tout en empêchant les mouvements latéraux pour une meilleure sécurité de Docker.

Comment le régler ?

Vous pouvez spécifier les réseaux Docker au moment de l'exécution ou dans votre configuration Docker Compose. Cependant, vous devez d'abord créer le réseau :

docker network create your-isolated-network

Au moment de l'exécution, ajoutez l'élément --option réseaun : docker run --network your-isolated-network your-app:v1.0.1

Ou l'option équivalente dans votre fichier Docker Compose :

les services : 
	webapp :    
    	 image : your-app:v1.0.1    
        networks: 
        	- votre-réseau-isolé    
		...

Définir un utilisateur non-root approprié

Que gagnez-vous ?

L'utilisateur par défaut dans un conteneur est racineavec un uid de 0. En spécifiant un utilisateur distinct, vous empêchez un attaquant d'escalader ses privilèges vers un autre utilisateur qui peut agir sans restriction, comme root, ce qui annulerait toutes les autres mesures de sécurité Docker que vous avez travaillé dur pour mettre en œuvre.

Comment le régler ?

Créez votre utilisateur au cours du processus de construction ou d'exécution. Lors de l'exécution, vous pouvez soit créer l'utilisateur pour la première fois, soit remplacer la fonction UTILISATEUR que vous avez déjà défini lors de la construction.

Pendant le processus de construction, dans votre Fichier Docker:

...
RUN groupadd -r votre-utilisateur
RUN useradd -r -g votre-utilisateur votre-utilisateur
USER mon utilisateur
...

‍

Au moment de l'exécution : docker run -u votre-utilisateur votre-app:v1.0.1

Abandonner les capacités du noyau Linux

Que gagnez-vous ?

Par défaut, les conteneurs Docker sont autorisés à utiliser un ensemble restreint de fonctionnalités du noyau Linux. On pourrait penser que les gens de Docker ont créé cet ensemble restreint pour qu'il soit complètement sécurisé, mais de nombreuses capacités existent pour des raisons de compatibilité et de simplicité. Par exemple, les conteneurs par défaut peuvent arbitrairement changer la propriété des fichiers, modifier leur répertoire racine, manipuler les UID des processus et lire les sockets. En abandonnant tout ou partie de ces capacités, vous minimisez le nombre de vecteurs d'attaque.

Comment le régler ?

Vous pouvez supprimer des capacités et en définir de nouvelles au moment de l'exécution. Par exemple, vous pouvez supprimer toutes les capacités du noyau et n'autoriser votre conteneur qu'à modifier la propriété des fichiers existants.

docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1

‍

Ou pour Docker Compose :

services :
	webapp :
    	 image : your-app:v1.0.1
        cap_drop: 
        	- ALL
        cap_add: 
        	- CHOWN
        ...

Prévenir les bombes à fourchette

Que gagnez-vous ?

Les bombes à fourche sont un type d'attaque DoS qui réplique à l'infini un processus existant. Tout d'abord, ils réduisent les performances et limitent les ressources, ce qui augmente inévitablement les coûts et peut finalement faire planter vos conteneurs ou le système hôte. Une fois qu'une bombe à fourche a démarré, il n'y a pas d'autre moyen de l'arrêter que de redémarrer le conteneur ou le système hôte.

Comment le régler ?

Au moment de l'exécution, vous pouvez limiter le nombre de processus (PID) que votre conteneur peut créer.

docker run --pids-limit 99 votre-app:v1.0.1

‍

Ou avec Docker Compose :

services :
	webapp :
		image : your-app:v1.0.1
deploy
			limites:
				pids : 99

‍

Améliorez la sécurité de Docker en surveillant vos dépendances open source

Que gagnez-vous ?

Les applications que vous avez conteneurisées pour les déployer avec Docker ont probablement une large arborescence de dépendances.

Comment le régler ?

Le moyen le plus "non-BS" est l'analyse des dépendances open-source d'Aikido. Notre surveillance continue analyse les projets écrits dans plus d'une douzaine de langues en se basant sur la présence de lockfiles dans votre application et fournit une vue d'ensemble instantanée des vulnérabilités et des logiciels malveillants. Grâce au triage automatique qui filtre les faux positifs, Aikido vous donne des conseils de remédiation que vous pouvez commencer à appliquer immédiatement... et pas seulement après avoir lu une douzaine d'autres documents de référence et de problèmes GitHub.

Chez Aikido, nous aimons les projets open-source bien établis comme Trivy, Syft et Grype. Nous savons aussi par expérience que les utiliser de manière isolée n'est pas une expérience particulièrement agréable pour les développeurs. Sous le capot, Aikido améliore ces projets avec des règles personnalisées pour combler les lacunes et révéler les failles de sécurité que vous n'auriez pas pu trouver autrement. Contrairement à l'enchaînement de divers outils open-source, Aikido vous évite d'avoir à construire un script d'analyse ou à créer un travail personnalisé dans votre CI/CD.

Utiliser uniquement des images de confiance pour la sécurité de Docker

Que gagnez-vous ?

Docker Content Trust (DCT) est un système de signature et de validation du contenu et de l'intégrité des images officielles que vous tirez des registres Docker comme Docker Hub. Le fait de n'extraire que des images signées par l'auteur vous donne l'assurance qu'elles n'ont pas été modifiées pour créer des vulnérabilités dans votre déploiement.

Comment le régler ?

La méthode la plus simple consiste à définir la variable d'environnement dans votre shell, ce qui vous empêche, ainsi que toute autre personne, de travailler avec des images non fiables.

exportDOCKER_CONTENT_TRUST=1
docker run ...

Vous pouvez également définir la variable d'environnement à chaque fois que vous exécutez Docker :

DOCKER_CONTENT_TRUST=1 docker run ...

Mise à jour des durées d'exécution en fin de vie (EOL)

Que gagnez-vous ?

Une recommandation courante pour la sécurité des conteneurs Docker est d'épingler les images et les dépendances à une version spécifique au lieu de les épingler à une version spécifique. le plus récent. En théorie, cela vous empêche d'utiliser à votre insu de nouvelles images, même celles qui ont été falsifiées, qui introduisent de nouvelles vulnérabilités.

Comment le régler ?

Vous disposez de quelques projets open-source pour vous aider à découvrir les dates de fin de vie et à vous préparer au mieux. Le projet endoflife.date(dépôt GitHub) suit plus de 300 produits en regroupant des données provenant de sources multiples et en les mettant à disposition via une API publique. Quelques options s'offrent à vous avec endoflife.date et d'autres projets similaires :

• Vérifier manuellement le projet pour les mises à jour des dépendances sur lesquelles vos applications s'appuient et créer des tickets ou des problèmes pour les mises à jour nécessaires.
• Écrire un script (Bash, Python, etc.) pour obtenir les dates de fin de vie des dépendances à partir de l'API et l'exécuter régulièrement, comme une tâche cron.
• Incorporez l'API publique, ou ce script personnalisé, dans votre plateforme CI pour faire échouer les constructions qui utilisent un projet dont la fin de vie est proche ou atteinte.

En tant que développeur, nous comprenons que votre temps est précieux et souvent limité. C'est là qu'Aikido peut vous apporter un sentiment de sécurité - notre fonction d'analyse EOL suit votre code et vos conteneurs, en priorisant les runtimes ayant le plus d'impact et d'exposition, comme Node.js ou un serveur web Nginx. Comme d'habitude, nous ne nous contentons pas d'automatiser la collecte d'informations, mais nous émettons des alertes d'une sévérité appropriée pour vous informer et non vous submerger.

Limiter l'utilisation des ressources du conteneur

Que gagnez-vous ?

Par défaut, les conteneurs n'ont pas de contraintes de ressources et utilisent autant de mémoire ou de CPU que le planificateur de l'hôte. Limiter l 'utilisation des ressources d'un conteneur spécifique peut minimiser l'impact d'une attaque par déni de service. Au lieu de faire planter votre conteneur ou votre système hôte en raison d'une exception de mémoire insuffisante, l'attaque DoS en cours n'aura qu'un impact négatif sur l'expérience de l'utilisateur final.

Comment le régler ?

Au moment de l'exécution, vous pouvez utiliser la fonction --Mémoire et --cpus pour définir les limites d'utilisation de la mémoire et du processeur, respectivement. L'option memory prend des nombres avec g pour gigaoctets et m pour mégaoctets, tandis que l'option CPU reflète la limite des CPU dédiés disponibles pour le conteneur et ses processus.

docker run --memory="1g" --cpus="2" votre-app:v1.0.1

Cela fonctionne également avec Docker Compose :

services :
	webapp :
    	 image : your-app:v1.0.1
        deploy: 
            limites :
            	 cpus : '2'
                memory: 1G 
         ...

Votre dernière commande et les options de Compose pour la sécurité de Docker

Vous avez maintenant vu un certain nombre de conseils de sécurité Docker et les options CLI pertinentes ou la configuration qui les accompagne, ce qui signifie que vous êtes soit très enthousiaste à l'idée de les mettre en œuvre, soit submergé par la façon de les assembler. Ci-dessous, nous avons regroupé toutes les recommandations en une seule commande ou un seul modèle de configuration, ce qui vous aidera à déployer des conteneurs Docker plus sûrs dès maintenant.

Il est évident que vous voudrez modifier certaines options, comme le nom de l'utilisateur non root, les capacités du noyau, les limites de ressources, en fonction des besoins de votre application.

exportDOCKER_CONTENT_TRUST=1
docker run \N--Lire la suite  
    --read-only (lecture seule) \N--Security-opt=no-new-privileges (sécurité)  
   --security-opt=no-new-privileges\N--Configuration du réseau\N--Configuration du réseau \N--Sécurité 
    --network your-isolated-network \N--cap-drop ALL  
    --cap-drop ALL 
    --cap-add CHOWN \N- --pids-limit 99  
    --pids-limit 99 \N 
    --memory="1g" --cpus="2" \N-user=votre-utilisateur \N--cap-drop ALL  
    --user=votre-utilisateur \N  
    ...                 # LES AUTRES OPTIONS VONT ICI  
    votre-app:v1.0.1

Vous pouvez même créer un alias drun avec l'interpréteur de commandes de votre hôte que vous pouvez invoquer sans avoir à vous souvenir de tous ces détails.

function drun  { 
docker run \N  
    	--read-only (lecture seule) \N-security-opt=no-new-privileges (sécurité)    
       --security-opt=no-new-privileges\N--concernant le réseau de votre réseau isolé\N 
        --network your-isolated-network \N--cap-drop ALL   
        --cap-drop ALL 
        --cap-add CHOWN \N- --pids-limit 99  
        --pids-limit 99 \N 
        --memory="1g" --cpus="2" \N-user=votre-utilisateur \N--cap-drop ALL   
        --user=votre-utilisateur \N  
       $1 \ 
       $2
}

Ensuite, lancez votre alias comme suit, avec vos options et le nom de l'image : drun -it your-app:v1.0.1

Si vous êtes un adepte de Docker Compose, vous pouvez adapter toutes les mêmes options dans un nouveau modèle de base de Docker Compose à partir duquel vous pourrez travailler à l'avenir :

services :
	webapp :
    	 image : your-app:v1.0.1
        read_only: true
        security_opt:
           - no-new-privileges:true
        networks: 
           - votre-réseau-isolé
        cap_drop: 
           - ALL
        cap_add: 
           - CHOWN
        deploy: 
        	limits :
        		 pids : 9
        		 cpus: '2'
        		memory: 1G 
        ...               # D'AUTRES OPTIONS VONT ICI

Bonus : Exécuter Docker avec des conteneurs sans racine

Lorsque vous installez Docker sur un système, son démon fonctionne avec des privilèges de niveau racine. Même si vous activez toutes les options ci-dessus et que vous empêchez l'escalade des privilèges au sein d' un conteneur Docker, le reste de l'exécution du conteneur sur votre système hôte dispose toujours des privilèges root. Cela élargit inévitablement votre surface d'attaque.

La solution réside dans les conteneurs sans racine, qu'un utilisateur non privilégié peut créer et gérer. L'absence de privilèges root signifie beaucoup moins de problèmes de sécurité pour votre système hôte.

Nous aimerions pouvoir vous aider à utiliser des conteneurs sans racine avec une seule option ou commande, mais ce n'est pas si simple. Vous trouverez des instructions détaillées sur le site web Rootless Containers, y compris un guide pratique pour Docker.

Quelle est la prochaine étape pour votre sécurité Docker ?

‍

Si vous avez appris quelque chose de cette expérience, c'est que la sécurité des conteneurs est une opération de longue haleine. Il y a toujours plus de checklists de renforcement et d'articles de fond à lire sur le verrouillage de vos conteneurs dans Docker ou son cousin plus ancien et souvent mal compris, Kubernetes. Vous ne pouvez pas viser une sécurité des conteneurs sans faille - créer du temps dans votre calendrier de développement chargé pour aborder la sécurité, puis apporter des améliorations incrémentales basées sur l'impact et la gravité, vous permettra d'aller loin au fil du temps.

Pour vous aider à maximiser ce processus continu et à prioriser les correctifs qui amélioreront de manière significative la sécurité de vos applications, il y a Aikido. Nous venons de lever une série A de 17 millions de dollars pour notre plateforme de sécurité pour développeurs "no BS", et nous serions ravis que vous nous rejoigniez.

Pourquoi êtes-vous ici ?

Vous avez déjà entendu parler des attaques par injection SQL de JavaScript, mais vous ne savez pas exactement à quoi elles ressemblent dans la nature ni si vous devez vous en préoccuper. Vous essayez peut-être de comprendre à quel point cela peut être grave.

En bref, si vous créez des applications utilisant des bases de données SQL, telles que MySQL et PostgreSQL, vous courez un risque : vous n'êtes pas à l'abri des méthodes d'attaque qui touchent les développeurs et leurs bases de données depuis des dizaines d'années. En tant que développeur, il vous incombe de mettre en place des garde-fous qui protègent les données des utilisateurs et garantissent que votre infrastructure sous-jacente ne fait jamais l'objet d'une intrusion, d'une exploration ou d'une réquisition.

Tous les nouveaux outils prétendent vous aider, mais ils ne font que rendre le développement plus complexe.

Vous pouvez ajouter un mappeur objet-relationnel (ORM) comme Sequelize et TypeORM pour simplifier la façon dont vous travaillez avec des bases de données SQL comme MySQL et PostgreSQL, mais ils ne vous exonèrent pas complètement du risque. Les pare-feu pour applications web (WAF) vous aident à bloquer les attaques au niveau du réseau, mais ils nécessitent une infrastructure coûteuse et une maintenance constante. Les scanners de code peuvent vous aider à identifier les failles évidentes, mais ils sont beaucoup moins efficaces pour les inconnues et les techniques de type "zero-day" qui se cachent.

Nous vous présenterons une image claire de ce à quoi ressemblent les attaques par injection SQL, du risque qu'elles comportent et des erreurs de développement qui les rendent possibles. Ensuite, nous vous accompagnerons dans l'installation d'un correctif global afin que vous sachiez, avec certitude, que vos applications sont sûres.

Attaques par injection SQL : exemples et implications

La définition la plus élémentaire d'une attaque par injection SQL est qu'une application permet à une entrée utilisateur non validée et non nettoyée d'exécuter des requêtes de base de données, ce qui permet à un attaquant de lire la base de données SQL, de modifier des enregistrements ou de les supprimer à sa guise.

Comme d'habitude, XKCD illustre le danger de SQL mieux que la plupart des scénarios sombres que nous pourrions imaginer :

À quoi ressemble une application JavaScript vulnérable ?

Commençons par un exemple de pseudocode simple : une application JavaScript avec un élément d'entrée qui permet aux utilisateurs de faire une recherche dans une base de données de chats. Dans l'exemple de code JavaScript ci-dessous, l'application répond aux requêtes POST sur le chemin /cats pour extraire l'entrée de l'utilisateur du corps de la requête et se connecte à la base de données avec une requête pour retourner tous les chats avec un identifiant correspondant. L'application affiche ensuite le chat à l'aide de la réponse JSON.

app.post("/cats", (request, response) => {
	const query = `SELECT * FROM cats WHERE id = ${request.body.id}`;
	connection.query(query, (err, rows) => {
    	if(err) throw err;
        response.json({
        	data: rows
		});  
	});
});

Bien que cet exemple puisse sembler inoffensif pour ceux qui n'ont pas été formés aux attaques par injection SQL, il est extrêmement vulnérable. Notamment, l'application ne tente pas de valider ou d'assainir l'entrée de l'utilisateur pour les chaînes de caractères ou les méthodes d'encodage potentiellement dangereuses, etconcatène l'entrée de l'utilisateur directement dans la requête SQL, ce qui donne aux attaquants de multiples occasions d'attaquer en utilisant des méthodes d'attaque par injection SQL courantes qui existent depuis des dizaines d'années.

Exemple de charges utiles d'attaque JavaScript SQL

L'injection SQL consiste à tromper votre base de données MySQL ou PostgreSQL pour qu'elle effectue une action ou réponde avec des données en dehors du cadre prévu, en raison de la manière dont votre application génère des requêtes SQL.

Le 1=1 est toujours vrai L'attaque peut retourner toute la table des chats avec des astuces comme les apostrophes ou les guillemets, parce que 1=1 est en effet toujours VRAI :

• L'utilisateur saisit les données : BOBBY TABLES" OU 1="1
• La base de données exécute la requête SQL : SELECT * FROM Users WHERE Cat = BOBBY TABLES OR 1=1 ;

De même, les attaquants peuvent exploiter une = est toujours vrai attaque pour renvoyer tous les chats, car ""="" est toujours VRAI :

• L'utilisateur saisit les données : " OR ""="
• La base de données exécute la requête SQL : SELECT * FROM Cats WHERE CatId ="" ou ""="" ;

Les attaquants exploitent souvent la manière dont les bases de données gèrent les commentaires en ligne, et en insérant des commentaires (/* ... */) dans une requête, ils peuvent obscurcir leur intention ou contourner les filtres.

• L'utilisateur saisit les données : DR/*hello world*/OP/*sneak attack*/ TABLE Cats ;
• La base de données exécute la requête SQL : DROP TABLE Cats ;

Une autre stratégie courante d'injection SQL en JavaScript est l'empilement de requêtes, qui permet aux attaquants de commencer par une chaîne inoffensive, puis d'utiliser un point-virgule ( ;) pour mettre fin à cette déclaration et en commencer une autre contenant leur injection. Les attaquants utilisent souvent l'empilement de requêtes pour supprimer des bases de données entières d'un seul coup à l'aide d'une commande DROP TABLE :

• L'utilisateur saisit les données : Bobby ; DROP TABLE Cats --
• L'application construit sa requête SQL : const query = "SELECT * FROM Cats WHERE CatId = " + input ;
• La base de données exécute la requête SQL : SELECT * FROM Cats WHERE CatId = BOBBY ; DROP TABLE Cats ;

Qu'en est-il des attaques par injection NoSQL ?

Les attaques par injection NoSQL sont tout aussi dangereuses pour la sécurité de votre application et des données des utilisateurs, mais elles n'affectent que les piles technologiques utilisant des bases de données telles que MongoDB. La principale différence réside dans le style des attaques, car les requêtes SQL et NoSQL utilisent une syntaxe totalement unique qui ne se traduit pas d'une catégorie à l'autre.

Si vous utilisez une base de données SQL, vous ne risquez pas d'être victime d'une attaque par injection NoSQL, et vice versa.

Le chemin de base : corriger manuellement toutes les vulnérabilités d'injection SQL

À ce stade, vous êtes peut-être moins intéressé par la description de toutes les astuces d'injection possibles que par la manière de protéger les données que vous avez dans MySQL ou PostgreSQL.

• Utiliser des requêtes paramétrées: SQL dispose d'une fonctionnalité permettant de déconnecter l'exécution des requêtes et des valeurs, protégeant ainsi la base de données des attaques par injection.Avec l'exemple JavaScript/Node.js ci-dessus, vous pouvez employer un espace réservé dans votre requête SQL avec un point d'interrogation (?). Les connexion.query() prend alors le paramètre en deuxième argument, ce qui donne les mêmes résultats dans une méthode à l'épreuve des injections.

app.post("/cats", (request, response) => {  
	const query = `SELECT * FROM Cats WHERE id = ?`;  
    const value = request.body.id;  
    connection.query(query, value, (err, rows) => {    
    	if(err) throw err;    
        response.json({      
        	data: rows    
		});  
	});
});

‍

• Valider et assainir les entrées des utilisateurs: Si les requêtes paramétrées peuvent contribuer à protéger votre base de données SQL contre les intrusions et les attaques, vous pouvez également empêcher les utilisateurs de saisir des chaînes de caractères potentiellement dangereuses dans votre application.
  
  Une option consiste à ajouter à votre application des bibliothèques open-source pour l'assainissement et la validation. Par exemple, vous pouvez utiliser validator.js dans l'écosystème JavaScript/Node.js pour vérifier qu'un utilisateur essaie d'entrer une véritable adresse électronique - et non une attaque par injection SQL - dans votre formulaire d'inscription.
  
  Vous pouvez également développer des validateurs personnalisés basés sur des expressions rationnelles pour effectuer un travail similaire, mais le chemin à parcourir sera extrêmement long et complexe, avec des recherches et des tonnes de tests manuels. De plus, pouvez-vous vraiment interpréter cet exemple de regex pour la validation d'un courriel ?
  
  const re = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  
  La même idée s'applique pour empêcher les chaînes de caractères comme ...' OR 1-'1. Vous pouvez essayer de rechercher et de fermer toutes ces opportunités vous-même, mais vous préférerez probablement passer votre temps à créer de nouvelles fonctionnalités.

‍

• Déployer des WAF ou des plateformes de sécurité basées sur des agents: Bien que ces solutions puissent bloquer les attaques SQL avant même qu'elles ne touchent votre application, ou au moins vous avertir en temps réel lorsque des attaques se produisent, elles sont assorties de quelques mises en garde.
  
  Tout d'abord, elles sont souvent coûteuses et vous obligent à lancer une nouvelle infrastructure sur site ou dans le nuage, ce qui est souvent beaucoup plus complexe que ce que vous avez signé en tant que développeur qui veut juste expédier à la production. Deuxièmement, elles nécessitent davantage de maintenance manuelle pour mettre à jour le jeu de règles, ce qui vous empêche d'effectuer d'autres interventions manuelles en cas d'injection de code SQL. Enfin, ils ajoutent souvent une charge de calcul supplémentaire ou redirigent toutes les requêtes via leur plateforme d'analyse, ce qui augmente la latence et nuit à l'expérience de l'utilisateur final.

Le gros problème est que les possibilités d'attaques par injection SQL sont comme des mauvaises herbes - vous pouvez les couper une fois à l'aide de ces outils, mais vous devez être constamment vigilant sur l'ensemble de votre base de code pour vous assurer qu'elles ne repoussent jamais.

Une voie alternative pour résoudre les attaques JavaScript par injection SQL : Pare-feu Aikido

Aikido Security a récemment publié Firewall, un moteur de sécurité gratuit et open-source qui vous protège de manière autonome contre les attaques par injection SQL et bien d'autres choses encore.

Si vous n'utilisez pas Node.js, sachez que nous prendrons en charge d'autres langages et frameworks à l'avenir. Vous pouvez toujours vous abonner à notre bulletin d'information sur les produits pour savoir exactement quand Firewall s'étendra au-delà du monde JavaScript ou nous envoyer un courriel à hello@aikido.dev si vous souhaitez parler d'un langage spécifique.

Tester une application vulnérable à l'injection SQL JavaScipt

Nous allons utiliser un exemple d'application fourni avec le dépôt open-source pour montrer comment fonctionne Aikido Firewall. Vous aurez également besoin de Docker/DockerCompose pour déployer une base de données MySQL locale.

Commencez par forker le dépôt firewall-node et clonez ce fork sur votre station de travail locale.

git clone https://github.com/<YOUR-GITHUB-USERNAME>/firewall-node.gitcd firewall-node

Utilisez Docker pour déployer une base de données MySQL locale sur le port 27015. Ce fichier docker-compose.yml crée également des conteneurs s3mock, MongoDB et PostgreSQL, car il a été créé pour aider l'équipe d'Aikido à tester la façon dont Firewall bloque diverses attaques.

docker-compose -f sample-apps/docker-compose.yml up -d

Lancez ensuite l'application modèle :

node sample-apps/express-mysql2/app.js

Ouvrir http://localhost:4000 dans votre navigateur pour découvrir cette application très simple. Dans la zone de texte, tapez quelques noms de chats et cliquez sur le bouton Ajouter pour tester l'injection d'un code SQL. Pour tester l'injection SQL, vous pouvez soit cliquer sur le bouton Injection de test ou tapez le texte suivant dans la zone de texte : Kitty') ; DELETE FROM cats;-- H et cliquez sur Ajouter à nouveau. Quoi qu'il en soit, l'application vous permet d'empiler plusieurs requêtes à l'aide de commentaires sournois, supprimant ainsi la totalité de la base de données des chats.

Comment cela se passe-t-il ? Comme nous l'avons déjà signalé, cette application ajoute simplement tous l'entrée de l'utilisateur à la fin de la requête SQL, ce qui n'est pas sûr par nature.

const query = `INSERT INTO cats(petname) VALUES ('${name}');`

Les conséquences peuvent être minimes, mais il n'est pas difficile d'imaginer comment cette erreur souvent honnête peut avoir des conséquences désastreuses pour votre application de production.

Blocage de l'injection JavaScript SQL avec Aikido Firewall

Voyons maintenant avec quelle rapidité notre moteur de sécurité open-source bloque les attaques JavaScript par injection SQL sans avoir à corriger manuellement chaque interaction avec la base de données dans votre code.

Si vous n'avez pas encore de compte Aikido, n'hésitez pas à en créer un. en faire un gratuitement. Si vous en avez déjà un, connectez-vous et connectez votre compte GitHub. Au cours de ce processus, accordez à l'Aikido l'accès à la lecture de votre fourche de l'accord. nœud de pare-feu projet.

Aller à la page Tableau de bord du pare-feu et cliquez sur Ajouter un service. Donnez un nom à votre service et choisissez à nouveau votre fourchette pour le service nœud de pare-feu projet.

Aikido vous explique ensuite comment installer et mettre en œuvre Aikido Firewall. Comme nous utilisons l'application d'exemple, ce travail est déjà fait pour vous, mais il s'agit d'une référence utile sur la façon d'apporter notre moteur de sécurité open-source à toutes vos applications Node.js qui pourraient être vulnérables à des attaques JavaScript par injection SQL.

Cliquez sur le bouton Générer un jeton pour créer un jeton permettant à Aikido Firewall de transmettre en toute sécurité les informations sur les attaques par injection SQL bloquées à la plateforme de sécurité Aikido. Copiez le jeton généré, qui commence par AIK_RUNTIME...et retournez à votre terminal pour réexécuter l'exemple d'application, mais maintenant avec le Pare-feu entièrement activé en mode blocage :

AIKIDO_TOKEN=<YOUR-AIKIDO-TOKEN> AIKIDO_DEBUG=true AIKIDO_BLOCKING=true node sample-apps/express-mysql2/app.js

Ouvrir localhost:4000 et invoque à nouveau l'attaque par injection SQL incluse. Cette fois, Aikido vous bloquera au niveau du navigateur, enverra un message dans les journaux de votre serveur web local et générera un nouvel événement. Cliquez sur cet événement pour obtenir des détails complets sur la tentative d'injection SQL, y compris la charge utile et l'endroit où votre application a généré la dangereuse requête SQL.

Au lieu de s'inquiéter de la protection permanente de vos applications contre les attaques par injection JavaScript SQL, qu'elles soient critiques ou non, Aikido Firewall offre un blocage complet et une observabilité sophistiquée qui vous tient informé des sources d'attaque, des charges utiles courantes et des points faibles potentiels.

Quelle est la prochaine étape ?

Vous pouvez installer et mettre en œuvre Aikido Firewall dans toutes vos applications basées sur Node.js gratuitement. Notre moteur de sécurité embarqué open-source protège votre infrastructure et les données de vos utilisateurs contre les attaques JavaScript SQL injection, l'injection de commandes, la pollution des prototypes, la traversée de chemin, et bien d'autres encore à venir prochainement.

Nous ne disons pas que Firewall devrait remplacer les meilleures pratiques de développement pour se protéger contre les injections SQL, comme l'utilisation de requêtes paramétrées ou le fait de ne jamais faire confiance à la saisie de l'utilisateur, mais nous savons aussi, par expérience personnelle, qu'aucun développeur n'est parfait. Aucune base de code n'est sans faille, et des erreurs honnêtes se produisent tout le temps.

Considérez Firewall comme un correctif global pour l'injection SQL. Contrairement aux expressions rationnelles développées sur mesure, aux WAFs induisant une latence ou aux agents de sécurité complexes qui coûtent une fortune, Firewall fait ce travail extraordinairement bien et avec un impact négligeable, et ce, tout à fait gratuitement.

Si vous aimez ce que vous avez vu, consultez notre feuille de route et donnez une étoile à notre dépôt GitHub(https://github.com/AikidoSec/firewall-node). ⭐

Introduction

Imaginez que vous construisiez une application web de blogging en utilisant Prisma. Vous écrivez une requête simple pour authentifier les utilisateurs sur la base de leur email et de leur mot de passe :

1const user = await prisma.user.findFirst({
2  where: { email, password },
3});

Cela semble inoffensif, n'est-ce pas ? Mais que se passe-t-il si un pirate envoie password = { "not": "" }? Au lieu de renvoyer l'objet Utilisateur uniquement lorsque l'adresse électronique et le mot de passe correspondent, la requête renvoie toujours l'objet Utilisateur lorsque seule l'adresse électronique fournie correspond.

Cette vulnérabilité est connue sous le nom d'injection d'opérateur, mais elle est plus communément appelée injection NoSQL. Ce que de nombreux développeurs ignorent, c'est qu'en dépit de schémas de modèles stricts , certains ORM sont vulnérables à l' injection d'opérateur même lorsqu'ils sont utilisés avec une base de données relationnelle telle que PostgreSQL, ce qui en fait un risque plus répandu qu'on ne le pense.

Dans ce billet, nous allons explorer le fonctionnement de l'injection d'opérateur, démontrer des exploits dans Prisma ORM, et discuter de la façon de les prévenir.

Comprendre l'injection d'opérateur

Pour comprendre l'injection d'opérateurs dans les ORM, il est intéressant d'examiner d'abord l'injection NoSQL. MongoDB a présenté aux développeurs une API permettant d'interroger les données à l'aide d'opérateurs tels que $eq, $lt et $ne. Lorsque les données de l'utilisateur sont transmises aveuglément aux fonctions d'interrogation de MongoDB, il existe un risque d'injection NoSQL.

Les bibliothèques ORM populaires pour JavaScript ont commencé à offrir une API similaire pour l'interrogation des données et maintenant presque tous les ORM principaux supportent une certaine variation des opérateurs de requête, même s'ils ne supportent pas MongoDB. Prisma, Sequelize et TypeORM ont tous implémenté le support des opérateurs de requête pour les bases de données relationnelles telles que PostgreSQL.

Exploitation de l'injection d'opérateur dans Prisma

Les fonctions de requête Prisma qui opèrent sur plus d'un enregistrement prennent généralement en charge les opérateurs de requête et sont vulnérables à l'injection. Voici quelques exemples de fonctions trouverPremier, findMany, updateMany et deleteMany. Bien que Prisma valide les champs du modèle référencés dans la requête au moment de l'exécution, les opérateurs sont une entrée valide pour ces fonctions et ne sont donc pas rejetés par la validation.

L'une des raisons pour lesquelles l'injection d'opérateurs est facile à exploiter dans Prisma est la présence d'opérateurs basés sur des chaînes de caractères dans l'API Prisma. Certaines bibliothèques ORM ont supprimé la prise en charge des opérateurs de requête basés sur des chaînes de caractères parce qu'ils sont facilement négligés par les développeurs et faciles à exploiter. Au lieu de cela, elles obligent les développeurs à référencer des objets personnalisés pour les opérateurs. Comme ces objets ne peuvent pas être facilement désérialisés à partir de l'entrée de l'utilisateur, le risque d'injection d'opération est considérablement réduit dans ces bibliothèques.

Toutes les fonctions de requête de Prisma ne sont pas vulnérables à l'injection d'opérateur. Les fonctions qui sélectionnent ou modifient un seul enregistrement de la base de données ne prennent généralement pas en charge les opérateurs et génèrent une erreur d'exécution lorsqu'un objet est fourni. En dehors de findUnique, les fonctions update, delete et upsert de Prisma n'acceptent pas non plus les opérateurs dans leur filtre where.

1  // This query throws a runtime error:
2  // Argument `email`: Invalid value provided. Expected String, provided Object.
3  const user = await prisma.user.findUnique({
4    where: { email: { not: "" } },
5  });

‍

Meilleures pratiques pour prévenir l'injection de l'opérateur

1. Conversion des données utilisateur en types de données primitives

En règle générale, il suffit de convertir les données d'entrée en types de données primitifs tels que les chaînes de caractères ou les nombres pour empêcher les attaquants d'injecter des objets. Dans l'exemple original, la conversion se présente comme suit :

1  const user = await prisma.user.findFirst({
2    where: { email: email.toString(), password: password.toString() },
3  });

2. Valider les données de l'utilisateur

Bien que le casting soit efficace, vous voudrez peut-être valider l'entrée de l'utilisateur pour vous assurer qu'elle répond aux exigences de votre logique d'entreprise.

Il existe de nombreuses bibliothèques pour la validation des données utilisateur côté serveur, telles que class-validator, zod et joi. Si vous développez pour un framework d'application web tel que NestJS ou NextJS, il est probable qu'ils recommandent des méthodes spécifiques pour la validation de l'entrée utilisateur dans le contrôleur.

Dans l'exemple original, la validation de zod pourrait se présenter comme suit :

1import { z } from "zod";
2
3const authInputSchema = z.object({
4  email: z.string().email(),
5  password: z.string().min(8)
6});
7
8const { email, password } = authInputSchema.parse({email: req.params.email, password: req.params.password});
9
10const user = await prisma.user.findFirst({
11  where: { email, password },
12});

3. Maintenez votre ORM à jour

Restez à jour pour bénéficier des améliorations et des corrections de sécurité. Par exemple, Sequelize a désactivé les alias de chaîne pour les opérateurs de requête à partir de la version 4.12, ce qui réduit considérablement la sensibilité à l'injection d'opérateur.

Conclusion

L'injection d'opérateur est une menace réelle pour les applications utilisant des ORM modernes. La vulnérabilité provient de la conception de l'API ORM et n'est pas liée au type de base de données utilisé. En effet, même Prisma combiné à PostgreSQL peut être vulnérable à l'injection d'opérateur. Bien que Prisma offre une protection intégrée contre l'injection d'opérateur, les développeurs doivent toujours pratiquer la validation et l'assainissement des entrées pour garantir la sécurité de l'application.

Annexe : Schéma Prisma pour le modèle de l'utilisateur

1// This is your Prisma schema file,
2// learn more about it in the docs: https://pris.ly/d/prisma-schema
3
4generator client {
5  provider = "prisma-client-js"
6}
7
8datasource db {
9  provider = "postgresql"
10  url      = env("DATABASE_URL")
11}
12
13// ...
14
15model User {
16  id       Int      @id @default(autoincrement())
17  email    String   @unique
18  password String
19  name     String?
20  posts    Post[]
21  profile  Profile?
22}

Les applications modernes sont livrées rapidement, ce qui signifie souvent que des bogues de sécurité se faufilent dans la production. Dans ce guide, nous expliquons ce qu'est le test dynamique de la sécurité des applications (DAST), pourquoi il est important en 2025 et comment choisir le bon outil DAST pour votre équipe, que vous soyez un développeur solo ou un responsable de la sécurité d'une entreprise.

Tous les lecteurs n'ont pas besoin d'aller en profondeur sur les 15 outils et plus. Si vous êtes ici avec un cas d'utilisation spécifique en tête - disons que vous recherchez le meilleur DAST pour les développeurs, les startups ou la sécurité des API - n'hésitez pas à passer directement aux sous-listes adaptées à votre scénario.

Cela dit, nous vous recommandons de vérifier la répartition complète des outils plus bas. Même un survol rapide de la liste principale peut faire apparaître un outil que vous n'aviez pas envisagé, ou vous aider à comprendre pourquoi certaines options se classent systématiquement en tête de toutes les catégories.

Qu'est-ce que DAST ?

Le test dynamique de la sécurité des applications (DAST) est une méthode de test de la sécurité qui évalue une application en cours d'exécution de l'extérieur vers l'intérieur, comme le ferait un attaquant. Un outil DAST interagit avec une application web par le biais de son interface (requêtes HTTP, interfaces web, API) sans avoir besoin d'accéder au code source. Cette approche "boîte noire" consiste à simuler des entrées malveillantes et à analyser les réponses de l'application afin d'identifier les vulnérabilités telles que les injections SQL, les scripts intersites (XSS), les failles d'authentification, les mauvaises configurations et d'autres problèmes d'exécution. En fait, DAST se comporte comme un pirate automatisé qui sonde les défenses de votre application.

Les solutions DAST se distinguent des outils d'analyse statique (SAST) car elles testent l'application en cours d'exécution dans un environnement réaliste. Alors que les SAST analysent le code source à la recherche de bogues, les DAST lancent des attaques sur une application déployée pour voir si ces vulnérabilités peuvent être exploitées en temps réel. Cela signifie que DAST peut trouver des problèmes qui ne se manifestent que lorsque l'ensemble du système fonctionne - par exemple, des erreurs de configuration, des contrôles d'accès non respectés ou des valeurs par défaut dangereuses qui ne seraient pas apparentes à la simple lecture du code. DAST est souvent utilisé dans les dernières phases de test (QA, staging, ou même production avec prudence) en tant que contrôle final pour détecter tout ce qui n'a pas été détecté auparavant.

En 2025, le DAST reste crucial car les applications web modernes sont de plus en plus complexes (applications à page unique, microservices, API, etc.). Les outils DAST ont évolué pour relever ces défis - explorer des interfaces riches, suivre des redirections, gérer des flux d'authentification et tester des API REST/GraphQL, le tout sans avoir besoin de voir les parties internes de l'application. De nombreuses entreprises adoptent une stratégie combinant SAST et DAST pour une couverture complète du cycle de vie du développement logiciel. (Pour une comparaison plus approfondie, voir notre guide sur l'utilisation conjointe de SAST et DAST).

Pourquoi vous avez besoin des outils DAST

La sécurité des applications web est une cible mouvante - les applications sont aujourd'hui exposées à l'internet 24 heures sur 24, 7 jours sur 7, et les attaquants découvrent sans cesse de nouveaux exploits. Voici pourquoi l'utilisation d'outils DAST est indispensable en 2025 :

• Couverture du monde réel : Les outils DAST détectent les vulnérabilités d'un point de vue extérieur, en vous montrant exactement ce qu'un attaquant pourrait exploiter dans une application en cours d'exécution. Ils peuvent mettre en évidence des problèmes dans l'environnement (configuration des serveurs, composants tiers, API) que les vérifications statiques du code pourraient manquer.
• Agnostique au niveau du langage et de la plateforme : Parce que DAST interagit avec l'application via HTTP et l'interface utilisateur, le langage ou le framework dans lequel l'application est écrite n'a pas d'importance. Un seul scanner DAST peut tester Java, Python, Node ou n'importe quelle plateforme web - idéal pour les environnements polyglottes.
• Détection des bogues critiques au niveau de l'exécution : DAST excelle à détecter des problèmes tels que des serveurs mal configurés, des flux d'authentification cassés, des cookies non sécurisés et d'autres problèmes de déploiement qui n'apparaissent que lorsque l'application est en ligne. Il s'agit souvent de vulnérabilités à fort impact (par exemple, un portail d'administration ouvert ou un mot de passe par défaut) qui échappent aux revues de code.
• Faibles faux positifs (dans de nombreux cas) : Les solutions DAST modernes utilisent des techniques telles que la vérification des attaques (par exemple, la preuve d'exploitation) pour confirmer les vulnérabilités et réduire le bruit. Contrairement au SAST, qui peut signaler des problèmes théoriques, le DAST montre généralement des preuves concrètes (comme "J'ai pu vider votre base de données par injection SQL"), ce qui permet aux développeurs de se fier plus facilement aux résultats.
• Conformité et tranquillité d'esprit : De nombreuses normes et réglementations de sécurité (PCI DSS, OWASP Top 10, etc.) recommandent ou exigent des tests dynamiques des applications web. L'utilisation d'un outil DAST permet de vérifier ces normes en produisant des rapports compréhensibles par les auditeurs (par exemple, la couverture des problèmes du Top 10 de l'OWASP) et de s'assurer que vous n'avez pas laissé de failles béantes dans votre application avant la mise en service.

En bref, DAST ajoute une couche de sécurité essentielle en attaquant votre application de la même manière que le feraient des menaces réelles, ce qui vous permet de corriger les faiblesses avant que des acteurs malveillants ne les exploitent.

Comment choisir un outil DAST

Tous les scanners DAST ne se valent pas. Lors de l'évaluation des outils de test dynamique de la sécurité des applications, il convient de prendre en compte les critères suivants pour trouver celui qui convient le mieux :

• Couverture des technologies : Assurez-vous que l'outil peut gérer la pile technologique de vos applications - prend-il en charge les frontaux modernes à forte composante JavaScript (applications à page unique), les backends mobiles et les API (REST, SOAP, GraphQL) ? Des outils comme HCL AppScan et Invicti prennent en charge un large éventail de types d'applications.
• Précision et profondeur : Recherchez des taux élevés de détection des vulnérabilités avec un minimum de faux positifs. Des fonctionnalités telles que les analyses de confirmation ou la génération de preuves de concept (par exemple, l'analyse basée sur la preuve d'Invicti) sont utiles pour valider automatiquement les résultats. Vous voulez un outil qui découvre des problèmes critiques mais qui ne vous submerge pas de bruit.
• Facilité d'utilisation et d'intégration : Un bon DAST s'intègre dans votre flux de travail. Considérez les outils qui offrent une installation facile (options basées sur le cloud ou gérées), une intégration CI/CD pour DevSecOps (Aikido, StackHawk, etc.), et des intégrations avec des traqueurs de problèmes (Jira, GitHub) ou des flux de travail. Si vos développeurs peuvent déclencher des analyses à partir de pipelines et obtenir des résultats dans leurs outils, l'adoption sera plus facile.
• Authentification et gestion de la complexité : De nombreuses applications ne sont pas entièrement publiques - vérifiez que le DAST prend en charge l'analyse authentifiée (connexion avec un compte utilisateur/une session) et qu'il peut gérer des éléments tels que des formulaires à plusieurs étapes ou des flux complexes. Les scanners d'entreprise tels que Burp Suite, AppScan et d'autres permettent d'enregistrer des séquences de connexion ou des scripts d'authentification.
• Rapports et commentaires des développeurs : Le résultat doit être convivial pour les développeurs. Il faut rechercher des descriptions claires des vulnérabilités, des conseils de remédiation et des rapports de conformité si nécessaire (par exemple, des rapports correspondant au Top 10 de l'OWASP, à la norme PCI, etc.) Certaines plateformes (comme DAST d'Aikido) fournissent même des suggestions de correction automatique ou des correctifs de code pour accélérer la remédiation.
• Évolutivité et performances : Si vous devez analyser des dizaines ou des centaines d'applications, réfléchissez à l'évolutivité de l'outil. Les services DAST basés sur le cloud (Qualys WAS, Rapid7 InsightAppSec, Tenable.io, etc.) peuvent exécuter des analyses en parallèle et gérer la planification. Les outils sur site doivent permettre l'utilisation de plusieurs moteurs ou agents d'analyse pour la mise à l'échelle. Évaluez également la vitesse d'analyse - certains outils offrent une analyse incrémentielle ou une optimisation pour des re-tests plus rapides.
• Assistance et maintenance : Enfin, la qualité d'un outil dépend de sa dernière mise à jour. Évaluez la fréquence à laquelle le fournisseur met à jour les contrôles de vulnérabilité de l'analyseur. Le soutien actif de la communauté ou du fournisseur est crucial, en particulier pour les options open-source. Un DAST obsolète (ou sans support) peut passer à côté de nouvelles menaces ou ne pas fonctionner avec des applications modernes.

Gardez ces critères à l'esprit lorsque vous examinerez le paysage des solutions DAST. Maintenant, plongeons dans les meilleurs outils disponibles en 2025 et voyons comment ils se positionnent.

Principaux outils DAST pour 2025

Dans cette section, nous dressons la liste des meilleurs outils de test dynamique de la sécurité des applications de 2025. Il s'agit d'un mélange d'options commerciales et open-source, chacune présentant des atouts uniques. Nous avons dressé une liste alphabétique des meilleurs outils, avec leurs principales caractéristiques, les cas d'utilisation idéaux, des informations sur les prix et même des extraits d'avis d'utilisateurs. Que vous soyez développeur dans une startup ou responsable de la sécurité dans une entreprise, vous trouverez une solution DAST adaptée à vos besoins.

Tout d'abord, voici une comparaison des 5 meilleurs outils DAST sur la base de fonctionnalités telles que l'analyse des API, l'intégration CI/CD et la précision. Ces outils sont les meilleurs de leur catégorie pour un éventail de besoins allant des développeurs aux équipes d'entreprise.

Acunetix par Invicti

Acunetix d'Invicti est un puissant scanner de vulnérabilités web axé sur DAST et conçu pour les petites et moyennes organisations. Il offre un balayage rapide et automatisé des sites Web et des API, en mettant l'accent sur la facilité d'utilisation et le déploiement rapide. Acunetix était à l'origine un produit autonome et fait maintenant partie de la famille de produits d'Invicti Security (en complément du scanner d'entreprise Invicti). Il constitue un excellent point d'entrée pour les équipes qui démarrent leur programme de sécurité des applications.

Caractéristiques principales :

• Couverture robuste des vulnérabilités : Analyse de plus de 7 000 vulnérabilités web connues, y compris tous les problèmes du Top 10 de l'OWASP, avec des contrôles pour SQLi, XSS, les mauvaises configurations, les mots de passe faibles, et bien plus encore.
• Balayage basé sur la preuve : Utilise la technologie propriétaire de preuve d'exploitation d'Invicti pour vérifier automatiquement de nombreux résultats, réduisant ainsi les faux positifs. Par exemple, il peut confirmer en toute sécurité les injections SQL en démontrant un échantillon d'extraction de données.
• Analyse des API et des SPA : Acunetix peut gérer les applications modernes - il explore les applications HTML5 à page unique et peut tester les API REST et GraphQL. Il prend également en charge l'importation des définitions Swagger/OpenAPI pour assurer une couverture complète des API.
• Intégrations et CI/CD : Offre des intégrations intégrées avec des systèmes de suivi des problèmes (comme Jira) et des pipelines CI/CD (Jenkins, GitLab CI, etc.) pour permettre l'automatisation dans DevSecOps. Les analyses peuvent être déclenchées sur les nouvelles versions et les résultats exportés sous forme de tickets de développeur pour des boucles de réparation rapide.
• Conformité et rapports : Fournit des rapports de conformité prêts à l'emploi pour des normes telles que OWASP Top 10, PCI DSS, HIPAA, ISO 27001, et bien d'autres encore - utiles pour les audits et la démonstration des tests de sécurité aux parties prenantes.

Idéal pour : Les petites et moyennes entreprises à la recherche d'un outil DAST rapide et facile à utiliser, doté d'un moteur d'analyse de qualité professionnelle. La tarification d'Acunetix est plus accessible que celle de certains outils de grandes entreprises (licences annuelles, avec options on-prem ou cloud).

‍Modèle de tarification: Commercial, avec des éditions basées sur le nombre de cibles ; un essai gratuit de 14 jours est disponible.

Points forts de l'évaluation : "Acunetix a une interface utilisateur conviviale, est facile à configurer et à utiliser, et produit des résultats fiables. Le modèle de licence n'est pas aussi granulaire qu'il pourrait l'être, ce qui signifie qu'il est nécessaire de planifier l'augmentation ou la réduction de la capacité." (Source : G2)

Sécurité de l'aïkido

Aikido Security est une plateforme de sécurité applicative tout-en-un axée sur les développeurs, qui comprend un scanner DAST ainsi que d'autres outils. Le DAST d'Aikido (appelé Surface Monitoring) simule des attaques en boîte noire sur votre application web pour trouver les vulnérabilités en temps réel. Aikido se distingue par son approche unifiée: il rassemble DAST, SAST, l'analyse de la sécurité des API, les vérifications de la configuration du cloud, et plus encore, dans une seule interface, offrant une expérience transparente aux développeurs et aux équipes de sécurité. La plateforme est basée sur le cloud, avec un niveau gratuit généreux, rendant la sécurité de niveau entreprise accessible aux startups comme aux grandes entreprises.

Caractéristiques principales :

• SAST + DAST unifiés : Aikido combine les tests statiques et dynamiques - vous pouvez détecter les problèmes de manière précoce avec SAST et les vérifier dans les applications en cours d'exécution avec DAST. Tous les résultats sont regroupés dans un seul tableau de bord pour une visibilité holistique de l'AppSec (cas d'utilisation SAST & DAST).
• Flux de travail convivial pour les développeurs : Conçu pour être une "sécurité simple pour les développeurs". Aikido s'intègre aux outils de développement (IDE, pipelines CI/CD, GitHub/GitLab, alertes Slack). Les développeurs obtiennent un retour d'information immédiat - par exemple, les résultats de DAST peuvent apparaître sous forme de commentaires de demande d'extraction ou de résultats de pipeline, avec des liens vers des suggestions de correction. Un utilisateur a déclaré : "Avec Aikido, la sécurité fait partie intégrante de notre façon de travailler. C'est rapide, intégré et réellement utile pour les développeurs."
• Découverte et analyse automatisées des API : Le moteur DAST comprend la découverte automatisée des points d'extrémité des API (REST et GraphQL) et les analyse pour détecter les vulnérabilités. Ceci est crucial car les APIs accompagnent souvent les applications web modernes. Aikido peut également se connecter et tester les zones authentifiées, augmentant ainsi la couverture de la surface d'attaque de votre application.
• Autofixation alimentée par l'IA : La plateforme d'Aikido peut générer des correctifs en un clic pour certaines découvertes grâce à l'IA. Par exemple, si le DAST trouve un XSS réfléchi, la plateforme peut suggérer un correctif de code ou un changement de configuration. Cela transforme les résultats de sécurité en tâches exploitables que les développeurs peuvent résoudre en quelques secondes.
• Évolutivité et intégration dans le cloud : En tant que service en nuage, Aikido est capable de scanner de nombreuses applications en continu. Il est adapté à l'échelle de l'entreprise (accès basé sur les rôles, tableaux de bord d'équipe pour l'utilisation en entreprise, etc. La plateforme peut fonctionner dans votre CI, ou vous pouvez déclencher des scans à la demande via une simple interface web ou une API.

‍Bestfor : Les équipes de développement qui souhaitent une solution de sécurité intégrée et centrée sur le développeur. Aikido est idéal si vous souhaitez intégrer DAST dans le cycle de vie du développement sans trop de frais généraux. Il est utilisé par les startups (il offre des plans spéciaux pour les startups) et les entreprises (voir les fonctionnalités pour les entreprises).

‍Modèle de tarification: Niveau gratuit pour toujours (qui comprend DAST, SAST et d'autres scanners de base pour les petits projets), et plans payants forfaitaires pour les utilisateurs supplémentaires ou les fonctionnalités avancées. Vous pouvez commencer gratuitement sans carte de crédit, ce qui facilite l'évaluation.

Points forts de l'évaluation : "Avec Aikido, nous pouvons résoudre un problème en seulement 30 secondes - cliquer sur un bouton, fusionner les RP, et c'est fait". (Feedback d'un utilisateur sur l'auto-remédiation)

Arachni

Arachni est un framework open-source d'analyse de la sécurité des applications web écrit en Ruby. Il s'agit d'un outil DAST riche en fonctionnalités qui a gagné en popularité grâce à son architecture modulaire et à ses capacités d'analyse approfondies. Arachni peut être utilisé comme un scanner autonome via son CLI ou son interface web, et c'est également un framework qui permet aux testeurs de pénétration de créer des modules de scan personnalisés. Bien qu'Arachni ne fasse pas l'objet d'un développement actif (la dernière mise à jour majeure date de 2017), il reste une option puissante pour ceux qui souhaitent travailler avec un projet open-source et potentiellement l'étendre.

Caractéristiques principales :

• Test de vulnérabilité approfondi : Arachni couvre toutes les vulnérabilités web critiques - injection SQL (y compris les techniques aveugles), XSS (réfléchi et stocké), inclusion de fichiers, injection de commandes OS, XXE, CSRF, et plus encore. Il effectue à la fois des vérifications actives (en attaquant les entrées) et des vérifications passives (en recherchant les fuites d'informations, les problèmes de configuration, etc.)
• Modulaire et extensible : Le scanner est très modulaire. Des dizaines de modules préconstruits gèrent différents types de tests, et vous pouvez écrire les vôtres en Ruby. Cette modularité s'étend aux paramètres du profil et même à la possibilité de distribuer des scans. Pour les utilisateurs avancés, Arachni peut être une boîte à outils de test de pénétration, et pas seulement un scanner à bouton-poussoir.
• Options d'interface graphique et de ligne de commande : Arachni offre une interface en ligne de commande pour l'automatisation et une interface graphique basée sur un navigateur pour une utilisation plus facile. Les utilisateurs moins expérimentés peuvent utiliser l'interface web pour configurer les analyses et consulter les rapports, tandis que les utilisateurs expérimentés peuvent intégrer l'interface CLI dans des scripts ou des pipelines de CI.
• Rapports détaillés : L'outil génère des rapports HTML détaillés avec des graphiques interactifs et des analyses approfondies des vulnérabilités. Les rapports expliquent chaque problème, en se référant souvent aux descriptions de l'OWASP, et incluent les étapes à suivre pour reproduire le problème et des suggestions pour y remédier. Ces rapports sont considérés comme l'un des points forts d'Arachni.
• Performance et automatisation : Il prend en charge l'analyse multithread et peut même être configuré de manière distribuée afin d'accélérer les analyses pour les applications volumineuses. Vous pouvez interrompre et reprendre les analyses, et adapter la portée de l'analyse pour cibler des domaines ou des pages spécifiques, ce qui est utile dans les scénarios d'automatisation.

Idéal pour : Les chercheurs en sécurité et les pen-testers qui souhaitent disposer d'un framework DAST gratuit et open-source pour bricoler. Arachni est également éducatif pour ceux qui apprennent comment les scanners fonctionnent sous le capot. Cependant, notez que le développeur d'Arachni a arrêté le développement actif, et le projet n'a pas connu de mises à jour majeures depuis 2017. Il fonctionne toujours pour de nombreux cas d'utilisation (grâce aux ajustements de la communauté) et peut trouver de nombreuses vulnérabilités, mais il peut ne pas gérer certaines technologies modernes (comme les cadres JavaScript les plus récents) de manière aussi fluide.

‍Modèle de tarification: Gratuit et open-source (GPLv2). Les utilisateurs doivent s'attendre à une courbe d'apprentissage en raison du support officiel minimal et de la nécessité de mettre à jour les modules pour les technologies de pointe.

Points forts de l'évaluation : "Progresse à travers tous les tests critiques pour le Top 10 de l'OWASP... Sortie de rapport impressionnante avec des explications perspicaces. Inconvénients : il n'a pas été mis à jour depuis 2017, pas de support, le projet a été abandonné." (Avis de Comparitech)

Suite d'éructation

Burp Suite de PortSwigger est un outil légendaire dans le monde de la sécurité web. Il s'agit d'une plateforme intégrée qui prend en charge les tests de sécurité des applications web, qu'ils soient manuels ou automatisés. Burp Suite est largement utilisé par les testeurs de pénétration, les chasseurs de bogues et les professionnels de la sécurité. Elle fonctionne comme un proxy d'interception (vous permettant de modifier le trafic) et comprend un scanner automatisé (Burp Scanner) pour DAST. Les outils modulaires de la suite (Proxy, Scanner, Intruder, Repeater, etc.) fournissent une boîte à outils de piratage complète. Burp Suite est disponible dans une édition communautaire gratuite et une édition professionnelle payante (avec beaucoup plus de fonctionnalités et de vitesse).

Caractéristiques principales :

• Proxy d'interception : Le cœur de Burp est un proxy qui intercepte les demandes et les réponses HTTP/S. Cela permet aux testeurs d'inspecter et de modifier le trafic à la volée. Cela permet aux testeurs d'inspecter et de modifier le trafic à la volée. Il est inestimable pour les tests manuels - vous pouvez manipuler les paramètres, les en-têtes, etc., puis envoyer des requêtes à d'autres outils Burp pour des tests plus poussés.
• Scanner automatisé : Le scanner DAST de Burp peut automatiquement explorer une application et rechercher des vulnérabilités. Il reconnaît d'emblée plus de 300 types de vulnérabilités, dont SQLi, XSS, CSRF, l'injection de commandes et d'autres. Avec plus de 2 500 cas de test et modèles, il est très complet. Les conclusions de l'analyseur comprennent des preuves et des conseils de remédiation.
• Extensibilité (magasin d'applications) : Burp dispose d'un vaste écosystème de plugins. Le BApp Store propose des extensions développées par la communauté qui ajoutent des fonctionnalités - des contrôles de vulnérabilité à l'intégration avec d'autres outils. Cela signifie que vous pouvez étendre Burp pour analyser les menaces émergentes ou l'intégrer à des pipelines de développement (il existe même un plugin Burp CI, et Burp Enterprise est un produit distinct pour l'automatisation).
• Outils de test manuel : Au-delà de l'analyse, Burp Suite se distingue par des outils tels que Intruder (pour le fuzzing/brute force automatisé), Repeater (pour créer et rejouer des requêtes individuelles), Sequencer (pour l'analyse des jetons), et Decoder/Comparer (décodeur/comparateur). Ces outils permettent aux testeurs qualifiés d'approfondir les problèmes spécifiques que l'analyse automatisée a mis en évidence.
• Intégration CI/CD : Pour les DevSecOps, PortSwigger propose Burp Suite Enterprise (une édition séparée) qui est conçue pour exécuter des analyses en CI et à l'échelle. Mais même Burp Pro peut être utilisé dans des scripts via la ligne de commande ou l'API. Cela permet aux équipes d'inclure des analyses Burp dans leur pipeline (souvent pour des applications critiques ou pour vérifier deux fois d'autres analyses).

Idéal pour : Les testeurs de pénétration et les organisations disposant d'experts en sécurité applicative. Burp Suite Professional est souvent utilisé pour les tests de sécurité pratiques en raison de sa flexibilité et de sa profondeur. Pour une équipe de développeurs, Burp peut être utilisé pour vérifier des problèmes spécifiques ou lors de la modélisation des menaces et du débogage des correctifs de sécurité. L'édition communautaire est gratuite mais comporte des limitations (analyse plus lente, pas d'état de sauvegarde). La licence Pro coûte environ 449 $ par utilisateur et par an - "elle vaut la peine pour les testeurs sérieux", comme l'a fait remarquer un utilisateur de Reddit : "C'est le moins cher et le meilleur outil de ce type. Il en vaut la peine". L'analyseur de Burp est puissant, mais il faut noter qu'il passe parfois à côté de problèmes très spécifiques à la logique d'entreprise - l'expertise humaine est son complément idéal.

Points forts de l'évaluation : "L'un des meilleurs outils proxy pour les chasseurs de bogues et les testeurs de pénétration. Il n'y a rien à redire, tous les professionnels l'adorent". (Avis G2)

HCL AppScan Standard

HCL AppScan Standard (anciennement IBM AppScan) est un outil DAST de bureau destiné aux entreprises. Il offre un ensemble riche de fonctionnalités permettant d'analyser les applications web, les services web et même certaines applications mobiles pour détecter les vulnérabilités en matière de sécurité. AppScan Standard fait partie du portefeuille plus large de HCL AppScan (qui comprend également AppScan Enterprise, AppScan on Cloud, les outils SAST, etc.) Il est connu pour ses capacités d'analyse approfondie et est souvent utilisé par les auditeurs de sécurité et les équipes d'assurance qualité dans les grandes organisations.

Caractéristiques principales :

• Moteur d'analyse complet : AppScan Standard utilise des algorithmes avancés d'exploration et de test pour maximiser la couverture des applications complexes. Son analyse "basée sur l'action" peut gérer des applications à page unique et un code côté client riche. Il dispose également de dizaines de milliers de cas de test intégrés qui couvrent tous les domaines, de SQLi à XSS en passant par les failles logiques. Il est conçu pour s'attaquer aux applications web les plus complexes avec des séquences de connexion, des flux de travail en plusieurs étapes, etc.
• Test d'API et de backend mobile : Au-delà des applications web traditionnelles, il peut tester les API web (SOAP, REST) et les backends mobiles. Vous pouvez lui fournir des définitions d'API ou enregistrer le trafic mobile pour auditer les points d'extrémité. AppScan est donc utile aux entreprises dont les applications mobiles communiquent avec des services JSON/REST.
• Analyses incrémentales et optimisées : Pour plus d'efficacité, AppScan permet une analyse incrémentale, c'est-à-dire qu'il ne teste que les parties nouvelles ou modifiées d'une application, ce qui permet de gagner du temps lors des tests de régression. Vous pouvez également ajuster les paramètres de vitesse d'analyse par rapport à la couverture afin de convenir à des analyses rapides de développement ou à des audits approfondis.
• Rapports et conformité : AppScan Standard possède de solides fonctions de reporting. Il peut générer une variété de rapports, y compris des rapports axés sur les développeurs avec des recommandations de correction et des résumés exécutifs. Il offre notamment des rapports de conformité et de normes industrielles (PCI, HIPAA, OWASP Top 10, DISA STIGs, etc.), ce qui permet de démontrer plus facilement le respect des exigences en matière de sécurité.
• Intégration à l'entreprise : Bien qu'AppScan Standard soit un client autonome, il peut s'intégrer à AppScan Enterprise (pour la mise à l'échelle des analyses au sein d'une équipe) et aux pipelines CI/CD par le biais d'une exécution en ligne de commande ou d'API. HCL fournit également des plugins pour des outils tels que Jenkins. En outre, il prend en charge l'analyse authentifiée avec divers mécanismes (Basic, NTLM, authentification par formulaire, etc.) et peut facilement fonctionner derrière le pare-feu de l'entreprise puisque vous l'exécutez sur site.

Idéal pour : Les entreprises et les équipes de sécurité qui ont besoin d'une solution DAST puissante sur site avec des options de configuration étendues. Si vous avez besoin d'un contrôle fin sur les analyses, de tester des applications dans un environnement sécurisé hors ligne ou si vous êtes soumis à des obligations de conformité, AppScan est un candidat de choix.

‍Modèle de tarification: Commercial (prix d'entreprise). En général, la licence est accordée par utilisateur ou par installation. HCL le propose également dans le cadre d'abonnements à AppScan on Cloud. Attendez-vous à un prix plus élevé correspondant à son ensemble de fonctionnalités d'entreprise ; une formation est recommandée pour en tirer le meilleur parti.

Contexte de l'évaluation : La longévité d'AppScan sur le marché (depuis l'époque d'IBM) signifie qu'il a été testé et éprouvé. Les utilisateurs font souvent l'éloge de sa profondeur mais notent que l'interface utilisateur et la configuration peuvent être complexes. Si vous y consacrez du temps, il trouvera de manière fiable les vulnérabilités et produira les rapports dont vous avez besoin pour satisfaire les auditeurs.

Micro Focus Fortify WebInspect

Micro Focus Fortify WebInspect (maintenant sous OpenText, qui a acquis Micro Focus) est un outil DAST d'entreprise connu pour son utilisation dans les évaluations de sécurité approfondies et son intégration avec la suite Fortify. WebInspect fournit une analyse dynamique automatisée des applications et services web, et il est souvent utilisé avec les outils d'analyse statique (SAST) de Fortify pour couvrir les deux angles. Cet outil a une longue histoire dans l'AppSec et est privilégié par les organisations qui ont besoin d'une analyse sur site et d'une intégration avec des programmes plus larges de gestion des vulnérabilités.

Caractéristiques principales :

• Analyse automatisée approfondie : WebInspect effectue des analyses rigoureuses qui permettent d'identifier un large éventail de vulnérabilités dans les applications web et les API. Il vérifie notamment le Top 10 de l'OWASP, les failles de la logique commerciale et les problèmes de configuration du serveur. Le scanner utilise un mélange de signatures et d'approches heuristiques pour découvrir les CVE connus ainsi que les problèmes de type "zero-day" (comme les cas limites de traitement d'entrée inhabituels).
• JavaScript et analyse côté client : Dans les versions récentes, Fortify WebInspect a amélioré son analyse du code côté client. Il peut exécuter JavaScript, gérer des applications à forte composante AJAX et même capturer des communications de socket web pendant les analyses (à partir des mises à jour 2024). Cela signifie que les SPA et les frameworks web modernes peuvent être audités plus efficacement.
• Intégration du flux de travail de l'entreprise : WebInspect s'intègre à l'écosystème Fortify - par exemple, les résultats peuvent être transférés dans Fortify Software Security Center (SSC) pour une gestion centralisée, une corrélation avec les résultats SAST et l'affectation des développeurs. Il dispose également d'API et d'une prise en charge de l'automatisation, ce qui lui permet de s'intégrer dans des pipelines de CI ou des systèmes d'orchestration de la sécurité. De nombreuses grandes organisations l'utilisent dans des flux d'analyse planifiés pour une surveillance continue.
• Analyses authentifiées et avec état : L'outil prend en charge une variété de méthodes d'authentification (y compris les techniques multifacteurs, les macros de connexion et l'authentification basée sur OAuth/token). Il peut maintenir l'état pendant l'analyse, ce qui est crucial pour les applications qui nécessitent une connexion et qui ont des flux d'utilisateurs complexes. WebInspect permet également l'enregistrement de macros pour parcourir des séquences spécifiques (comme l'ajout d'articles à un panier, puis le passage en caisse), ce qui garantit que ces zones sont testées.
• Rapports et conformité : Fortify WebInspect fournit des résultats techniques détaillés aux développeurs et des rapports de synthèse à la direction. Il aligne les résultats sur les normes et inclut des rapports de conformité. Parce qu'il est souvent utilisé dans des secteurs réglementés, il offre des rapports pour satisfaire les normes PCI DSS, DISA STIG, OWASP et d'autres directives dès le départ.

Idéal pour : Les grandes entreprises et les organisations gouvernementales ayant des exigences de sécurité strictes et des déploiements Fortify existants. WebInspect est puissant mais s'adresse à des experts en sécurité - il peut s'avérer excessif pour une petite équipe. Il excelle lorsqu'il est intégré à un programme AppSec mature (en particulier si Fortify SAST est également utilisé, ce qui permet d'obtenir une vue d'ensemble).

‍Modèle de tarification: Commercial. Généralement vendu dans le cadre de la suite de produits Fortify (licences verrouillées ou concurrentes). Les contrats de support vous garantissent des mises à jour régulières des signatures de vulnérabilités et des améliorations du produit.

Note : Après l'acquisition d'OpenText, Fortify WebInspect fait désormais partie du portefeuille OpenText Cybersecurity. Il est parfois appelé "OpenText Dynamic Application Security Testing (DAST)". Le produit de base est le même, poursuivant la tradition de WebInspect. Les utilisateurs ont noté que WebInspect peut être gourmand en ressources et peut nécessiter des réglages pour éviter de submerger certaines applications, mais il est très efficace pour découvrir des problèmes complexes.

Nessus

Nessus de Tenable est l'un des scanners de vulnérabilité les plus largement reconnus dans l'industrie. Bien que Nessus soit souvent considéré comme un scanner de réseau, il effectue également des analyses d'applications web (principalement pour vérifier les vulnérabilités connues des applications web, les mauvaises configurations et les faiblesses courantes). Il ne s'agit pas d'un crawler complet comme les outils DAST dédiés, mais il est inclus ici parce que de nombreuses équipes utilisent Nessus pour couvrir la sécurité de base des applications web en plus des scans réseau et système. Nessus offre une large couverture avec une énorme base de données de plugins de vérification des vulnérabilités.

Caractéristiques principales :

• Bibliothèque massive de vulnérabilités : Nessus couvre plus de 99 000 CVE et plus de 250 000 vérifications de plugins. Pour les applications web, il peut détecter des éléments tels que des versions obsolètes de CMS (WordPress, Joomla, etc.), des vulnérabilités connues dans les frameworks web, des configurations non sécurisées et la présence de fichiers ou de sauvegardes par défaut. C'est un excellent outil pour détecter les problèmes les plus courants et les problèmes connus.
• Tests d'applications Web : Nessus inclut des tests spécifiques au web tels que l'injection SQL, XSS, l'inclusion de fichiers locaux et la traversée de répertoires - mais il s'agit généralement de tests basés sur des signatures ou de tests simples. Il peut, par exemple, essayer quelques charges utiles génériques d'injection SQL ou tester des URL d'administration courantes. Il vérifie également le Top 10 de l'OWASP de manière générique. Cependant, il n'est pas aussi adapté à la logique de chaque application qu'un outil DAST dédié.
• Facilité d'utilisation : Nessus est réputé pour sa convivialité. Vous pouvez analyser une adresse IP ou une URL en quelques clics ou via la ligne de commande. Les rapports sont simples et les vulnérabilités sont classées par ordre de gravité. Pour un généraliste de l'informatique ou un ingénieur DevOps, Nessus offre un moyen unifié d'analyser à la fois les serveurs et les applications web qui s'y trouvent.
• Intégration à la plateforme Tenable : Nessus peut être utilisé de manière autonome (Nessus Professional) ou dans le cadre de Tenable.io ou Tenable.sc (Security Center) pour la gestion de l'entreprise. Lorsqu'ils sont intégrés, les résultats de l'analyse des applications Web font partie de votre tableau de bord global de gestion des vulnérabilités, en corrélation avec les vulnérabilités du réseau. Tenable.io Web App Scanning (produit distinct, voir ci-dessous) utilise en fait un moteur différent, mais Nessus lui-même dispose également de plugins web.
• Mises à jour continues : Nessus reçoit des mises à jour de plugins chaque semaine (ou plus rapidement pour les problèmes critiques) de l'équipe de recherche de Tenable. Cela signifie qu'il est rapide d'obtenir des vérifications pour les dernières CVE (par exemple, si un nouveau RCE Apache Struts est publié, Nessus dispose souvent d'un plugin pour le détecter en quelques jours). Ce cycle de mise à jour rapide est un grand avantage pour se tenir au courant des menaces émergentes.

Idéal pour : Compléter d'autres outils pour assurer une couverture complète. Nessus est un excellent outil de "premier passage" - il trouvera rapidement les faiblesses communes et les problèmes connus. Les petites organisations s'appuient parfois uniquement sur Nessus pour l'analyse des applications web, mais sa profondeur est limitée par rapport aux DAST spécialisés. L'idéal est d'utiliser Nessus en même temps qu'un scanner spécialisé dans les applications web (comme ceux mentionnés ci-dessus) afin de tout détecter.

‍Modèle de tarification: Nessus Essentials est une version gratuite (limitée à 16 adresses IP, idéale pour les petits projets ou l'apprentissage). Nessus Professional est un abonnement annuel payant (environ 2 790 $/an pour une analyse illimitée des adresses IP). Tenable.io (cloud) et Security Center (on-prem) incluent les scanners Nessus dans leurs plateformes, avec une licence par actif. Nessus est rentable car il ne couvre pas seulement les applications web.

Points forts de l'évaluation : "Nessus possède l'une des plus grandes bibliothèques de vérifications de vulnérabilités et de configurations, couvrant un large éventail de systèmes, d'appareils et d'applications. Bien que Nessus soit connu pour ses capacités complètes d'analyse des vulnérabilités, il peut parfois produire des faux positifs...". (Dans la pratique, les faux positifs sont généralement peu nombreux si Nessus est configuré correctement, mais comme l'indique la citation, il se peut que vous deviez vérifier manuellement certains résultats).

Netsparker (Invicti)

Netsparker (désormais connu sous le nom d'Invicti) est un scanner automatisé de sécurité des applications web pour les environnements d'entreprise. Netsparker a été rebaptisé Invicti au cours des dernières années après qu'Invicti Security a unifié les produits Netsparker et Acunetix sous un même toit. Invicti (Netsparker) est réputé pour sa précision - en particulier pour son utilisation du Proof-Based Scanning (analyse basée sur la preuve) afin d'éliminer virtuellement les faux positifs en confirmant réellement les vulnérabilités. Il s'agit d'un DAST complet qui intègre également des éléments de test interactifs pour une analyse plus approfondie.

Caractéristiques principales :

• Analyse basée sur la preuve : Invicti tente automatiquement de confirmer les vulnérabilités en les exploitant de manière sûre. Par exemple, s'il trouve une injection SQL, il exécutera une charge utile bénigne qui extrait un échantillon de données pour prouver le problème. Cela permet d'obtenir une précision d'analyse de 99,98 %, de sorte que vous pouvez faire confiance aux résultats et passer moins de temps à vérifier manuellement les découvertes.
• Support technologique étendu : Invicti peut scanner des applications web traditionnelles, des SPA avec beaucoup de JavaScript, et toutes sortes d'API (REST, SOAP, GraphQL, gRPC). Il gère efficacement les frameworks modernes et inclut la prise en charge de l'analyse des technologies d'entreprise (il peut naviguer à travers l'authentification personnalisée, gérer les jetons OAuth, etc.) Il est également capable de tester les corps de requête JSON et les enveloppes SOAP à la recherche de failles d'injection.
• Capacités hybrides IAST : Invicti combine le DAST avec un peu d'IAST (Interactive Application Security Testing) via sa technologie d'agent. Si vous pouvez déployer un agent léger à côté de votre application, le scanner peut instrumenter l'application pendant son exécution pour obtenir des informations supplémentaires (comme la confirmation de la ligne de code exacte pour une vulnérabilité). Cette approche hybride permet d'accroître la couverture et le niveau de détail sans nécessiter un accès complet au code source.
• CI/CD et intégration : Construit avec l'automatisation à l'esprit, Invicti fournit des options d'intégration robustes - des plugins pour les pipelines CI (Jenkins, Azure DevOps, GitLab CI, etc.), l'intégration avec la gestion de projet et le ticketing (Jira, Azure Boards), et même la liaison avec les WAFs pour le patching virtuel instantané. Il convient donc aux flux de travail DevSecOps qui nécessitent une analyse continue.
• Évolutivité et gestion : La plateforme peut évoluer pour analyser des milliers d'applications avec une planification, une priorisation et un contrôle d'accès basé sur les rôles pour une collaboration d'équipe. Invicti offre également un tableau de bord multi-locataires et des fonctions de découverte des actifs (il peut découvrir de nouvelles applications web dans votre environnement pour s'assurer qu'elles sont analysées). Il est souvent utilisé comme base pour la gestion de la vulnérabilité des applications web au sein de l'entreprise.

Idéal pour : Les moyennes et grandes entreprises qui ont besoin d'une solution DAST très précise et évolutive. Les équipes de sécurité qui sont frustrées par les faux positifs ou qui doivent convaincre les développeurs de corriger les problèmes trouvent les résultats validés très utiles ("le scanner a prouvé que c'est réel"). Invicti (Netsparker) est également un choix de premier ordre pour les organisations qui ont des centaines d'actifs web à analyser régulièrement.

‍Modèle de tarification: Commercial - abonnement annuel par site web ou application analysée (utilisation illimitée de l'analyse). Il se situe dans la partie supérieure du spectre des prix, ce qui reflète son orientation vers les entreprises. Il est possible de demander une démonstration ou un essai pour l'évaluer sur vos applications.

Points forts de la revue : "Invicti, qui est Netsparker, m'a fourni une importante base de données de vulnérabilités pour trouver des failles d'exécution à distance, l'invalidation de domaines et de nombreux correctifs de vulnérabilités... L'analyse récurrente me permet de récupérer des fichiers à un niveau d'intégrité". (Revue G2). En termes clairs : les utilisateurs apprécient la profondeur de la couverture des vulnérabilités et la possibilité de programmer des analyses répétées pour détecter les régressions. Certains notent que l'étendue des tests d'Invicti (plus de 1400 tests uniques) est énorme, bien que certaines fonctionnalités avancées puissent nécessiter un réglage fin.

Nikto

Nikto est un scanner de serveur web classique à code source ouvert. Il s'agit d'un outil simple mais efficace qui effectue des contrôles complets pour détecter des milliers de problèmes potentiels sur les serveurs web. Nikto est un outil en ligne de commande basé sur Perl et maintenu par CIRT.net, et il fait partie de la boîte à outils de sécurité depuis des années. Bien que Nikto n'ait pas l'interface soignée ou la logique complexe des scanners modernes, il est très utile pour identifier rapidement les vulnérabilités connues et les configurations non sécurisées.

Caractéristiques principales :

• Grande base de données de contrôles : Nikto peut tester plus de 7 000 fichiers/CGI potentiellement dangereux et les configurations sur un serveur web. Il s'agit notamment de vérifier les fichiers par défaut (comme les pages d'administration, les scripts d'installation), les exemples d'applications, les sauvegardes de configuration (*.old, *.bak ) et d'autres artefacts que les attaquants recherchent généralement. Il détecte également les versions obsolètes de plus de 1 250 serveurs et composants logiciels, ainsi que les problèmes spécifiques aux versions de plus de 270 produits serveurs.
• Vérifications de la configuration du serveur : Nikto ne se contente pas de rechercher les vulnérabilités des applications web ; il examine les informations relatives au serveur. Par exemple, il indique si l'indexation des répertoires est activée, si les méthodes HTTP telles que PUT ou DELETE sont autorisées (ce qui pourrait permettre le piratage des téléchargements de fichiers), ou si certains en-têtes HTTP non sécurisés sont présents/absents. Il s'agit d'un excellent outil d'audit rapide du durcissement des serveurs web.
• Rapide et sans fioritures : Nikto n'est pas furtif - il est conçu pour fonctionner aussi vite que possible et sera bruyant dans les journaux. C'est une bonne chose pour un balayage autorisé. Il est piloté en ligne de commande, vous pouvez donc lui fournir une liste d'hôtes ou l'utiliser dans des scripts facilement. Exécution nikto -h <hostname> produira une liste des problèmes identifiés en texte clair.
• Options de sortie : Nikto peut enregistrer les résultats dans plusieurs formats (texte brut, XML, HTML, NBE, CSV, JSON), ce qui est utile si vous souhaitez intégrer les résultats dans d'autres outils ou systèmes de reporting. De nombreuses personnes utilisent Nikto dans le cadre d'une boîte à outils plus large, en analysant ses résultats pour signaler certaines découvertes.
• Extensibilité : Bien qu'il ne soit pas aussi modulaire que d'autres, vous pouvez personnaliser le comportement de Nikto. Il supporte les plugins (sa base de données de contrôles est essentiellement un ensemble de plugins). Vous pouvez mettre à jour ses signatures, et il est fréquemment mis à jour par la communauté avec de nouveaux contrôles. Il prend également en charge les techniques anti-sida de LibWhisker si vous essayez d'être furtif (bien que, par défaut, il soit bruyant).

Idéal pour : Les scans rapides pour trouver les problèmes connus et comme complément aux scanners plus profonds. Nikto est apprécié par de nombreux testeurs de pénétration pour une reconnaissance initiale d'un serveur web cible. Si vous êtes un développeur ou un administrateur système, vous pouvez exécuter Nikto sur votre site pour détecter les problèmes évidents (et c'est souvent révélateur). Cependant, il ne trouvera pas de failles logiques complexes ou quoi que ce soit qui nécessite d'explorer JavaScript - ce n'est pas ce genre d'outil. Considérez Nikto comme une liste de contrôle automatisée pour les erreurs de configuration et les vulnérabilités courantes sur le web.

‍Modèle de tarification: Gratuit, open-source (GPL). Il est inclus dans des distributions de sécurité comme Kali Linux et peut être utilisé sans aucune contrainte de plateforme (script Perl). Le support est communautaire (forums, GitHub).

Astuce : Nikto étant passif en termes de logique (pas de login, pas de crawling lourd), il est très rapide. Vous pouvez intégrer Nikto dans un pipeline CI pour un balayage rapide de chaque build (pour s'assurer, par exemple, qu'aucun point d'extrémité de débogage n'a été accidentellement déployé). Bien qu'il puisse rapporter quelques résultats de niveau "info" qui ne sont pas de véritables vulnérabilités, il offre la tranquillité d'esprit que vous n'avez pas laissé quelque chose d'évident dans la nature.

OWASP ZAP

OWASP ZAP (Zed Attack Proxy) est un outil DAST gratuit et open-source maintenu dans le cadre du projet OWASP. C'est l'un des outils DAST les plus populaires en raison de son coût (gratuit), de sa communauté ouverte et de la richesse de ses fonctionnalités. ZAP est à la fois un proxy pour les tests manuels et un scanner automatisé. Il est souvent considéré comme l'alternative open-source à Burp Suite pour ceux qui disposent d'un budget limité, et c'est une option fantastique pour les développeurs et les petites entreprises qui souhaitent commencer à tester la sécurité sans se heurter à des obstacles en matière d'approvisionnement.

Caractéristiques principales :

• Analyse active et passive : ZAP effectue un balayage passif en observant le trafic qui passe par lui (via son proxy ou son spider) et en signalant les problèmes, et un balayage actif où il injecte activement des attaques une fois qu'il a découvert des pages. Le mode passif est idéal pour commencer en douceur (il ne modifiera rien, se contentant de surveiller les fuites d'informations ou les en-têtes de sécurité), tandis que l'analyse active trouvera les véritables bogues (SQLi, XSS, etc.) en attaquant l'application.
• Proxy et outils de test manuel : Comme Burp, ZAP peut fonctionner comme un proxy d'interception. Il dispose également d'une série d'outils : un proxy d'interception HTTP, un spider pour explorer le contenu, un fuzzer pour attaquer les entrées, et une console de script (avec un support pour écrire des scripts en Python, Ruby, etc. afin d'étendre ZAP). Le mode Heads-Up Display (HUD) vous permet même de superposer des informations d'analyse à votre navigateur pendant que vous naviguez - très utile pour les développeurs qui s'initient à la sécurité.
• Automatisation et API : ZAP a été conçu dans une optique d'automatisation pour l'intégration de l'assurance qualité. Il dispose d'une API puissante (REST et API Java) qui vous permet de contrôler tous les aspects de ZAP. De nombreuses équipes utilisent l'API ZAP dans les pipelines de CI - par exemple, démarrer ZAP en mode démon, spider une cible, exécuter un scan actif, puis extraire les résultats - le tout de manière automatisée. Il existe même des actions GitHub et des plugins Jenkins prêts à l'emploi pour ZAP. Il s'agit donc d'une solution idéale pour les DevSecOps disposant d'un budget réduit.
• Extensibilité grâce aux modules complémentaires : ZAP dispose d'un marché de modules complémentaires (le ZAP Marketplace) où vous pouvez installer des modules complémentaires officiels et communautaires. Il s'agit de règles d'analyse spécialisées (pour JSON, XML, SOAP, WebSockets, etc.), d'intégrations ou de fonctions pratiques. La communauté met constamment à jour les règles d'analyse, y compris les règles alpha/beta pour les nouveaux types de vulnérabilités. Les capacités d'analyse de ZAP sont ainsi en constante évolution.
• Communauté et soutien : En tant qu'OWASP, il dispose d'une forte communauté d'utilisateurs. Il existe une documentation abondante, des vidéos de formation gratuites et des forums actifs. Bien que vous n'obteniez pas de support commercial (à moins de faire appel à des consultants tiers), les connaissances disponibles rivalisent souvent avec le support des vendeurs. ZAP est également mis à jour régulièrement par les chefs de projet et les contributeurs.

Idéal pour : Les équipes de développement, les organisations soucieuses de leur budget et comme outil d'apprentissage. OWASP ZAP est idéal pour les développeurs qui souhaitent se lancer dans les tests de sécurité ("shift-left"). Il est également utilisé par les professionnels en conjonction avec Burp pour une perspective supplémentaire. Si vous êtes une startup, ZAP vous offre une capacité DAST sans coût de licence, ce qui est un énorme avantage.

Point fort de la critique : "L'outil OWASP est gratuit, ce qui lui confère un grand avantage, en particulier pour les petites entreprises qui souhaitent l'utiliser" peerspot.com. Ce sentiment est commun - ZAP abaisse la barrière à l'entrée de la sécurité web. Il ne dispose peut-être pas de fonctions haut de gamme comme certains scanners commerciaux, mais pour de nombreux cas d'utilisation, il permet de faire le travail efficacement.

Qualys Web Application Scanner (WAS)

Qualys Web Application Scanning (WAS) est une offre DAST basée sur le cloud de Qualys, intégrée dans sa suite de sécurité et de conformité QualysGuard. Qualys WAS s'appuie sur la plateforme cloud de Qualys pour fournir un service d'analyse à la demande pour les applications web et les API. Ce service est particulièrement intéressant pour les entreprises qui utilisent déjà Qualys pour l'analyse des vulnérabilités du réseau ou la mise en conformité, car il permet d'étendre aux applications web le principe du "single-pane-of-glass" (un seul point de vue). Qualys WAS est réputé pour son évolutivité (analyse de milliers de sites) et sa facilité d'utilisation via un modèle SaaS.

Caractéristiques principales :

• Basé sur le cloud et évolutif : Qualys WAS est fourni en tant que service - vous exécutez des analyses à partir du nuage Qualys contre vos cibles (avec la possibilité d'utiliser des appliances d'analyse distribuées pour les applications internes). Cela signifie qu'il n'y a pas de frais de maintenance pour l'outil lui-même et qu'il est possible d'exécuter de nombreuses analyses en parallèle. La plateforme a découvert et analysé plus de 370 000 applications web et API, ce qui montre qu'elle est largement utilisée.
• Large couverture des vulnérabilités : Il détecte les vulnérabilités, y compris le Top 10 de l'OWASP (SQLi, XSS, CSRF, etc.), les mauvaises configurations, l'exposition de données sensibles (par exemple, les numéros de carte de crédit dans les pages) et même l'infection par des logiciels malveillants sur les sites web. Il vérifie également l'exposition involontaire d'informations confidentielles ou de secrets dans les pages web. Qualys utilise un peu d'IA/ML (apprentissage automatique) dans son analyse pour améliorer la détection des problèmes complexes et réduire les faux positifs (d'après son marketing).
• Test de sécurité des API : Qualys WAS couvre également le Top 10 des API de l'OWASP. Il peut importer des fichiers OpenAPI/Swagger ou des collections Postman et tester minutieusement les API REST. Il surveille la "dérive" par rapport aux spécifications de l'API, ce qui signifie que si votre implémentation ne correspond pas au fichier Swagger (ce qui pourrait indiquer des points d'extrémité non documentés), Qualys peut le signaler. C'est très utile pour gérer la sécurité des API.
• Intégration et DevOps : Qualys propose une API complète pour tous ses produits, y compris WAS. Il est possible d'automatiser les analyses, d'obtenir des rapports et même d'intégrer les résultats dans des systèmes de suivi des défauts. Qualys dispose également d'un plug-in Chrome (Qualys Browser Recorder) pour enregistrer les séquences d'authentification ou les flux de travail des utilisateurs, qui peuvent être téléchargés dans Qualys WAS pour analyser les parties d'une application qui requièrent une connexion. En outre, les résultats de Qualys WAS peuvent alimenter leur WAF (si vous utilisez Qualys WAF) pour un correctif virtuel rapide.
• Conformité et rapports : Qualys étant très attaché à la conformité, WAS est en mesure de générer les rapports nécessaires pour répondre à la norme PCI DSS 6.6 (exigence d'analyse des vulnérabilités des applications web) et à d'autres politiques. Tous les résultats sont consolidés dans l'interface Qualys, qui peut être partagée avec d'autres modules tels que leurs outils de gestion des vulnérabilités ou de gestion des risques. Ce reporting unifié est un atout pour la direction.

Idéal pour : Les entreprises qui utilisent une plateforme de sécurité basée sur le cloud et qui souhaitent consolider l'analyse. Si vous utilisez déjà Qualys pour d'autres analyses de sécurité, l'ajout de WAS est une évidence pour couvrir les applications Web. C'est également une bonne solution si vous souhaitez une solution entièrement gérée (SaaS) et que vous ne voulez pas utiliser de scanners sur site. Qualys se chargeant des mises à jour, vous bénéficierez toujours des dernières améliorations en matière d'analyse sans avoir à lever le petit doigt.

‍Modèle de tarification: Qualys WAS est basé sur un abonnement, généralement sous licence par application web (avec des paliers basés sur le nombre d'applications ou d'IP scannées). Qualys vend souvent des offres groupées (par exemple, un ensemble comprenant la gestion des vulnérabilités + WAS). Une version d'essai gratuite est disponible et Qualys a tendance à proposer des prix orientés entreprise (ce n'est pas le moins cher, mais vous bénéficiez d'une plateforme robuste).

Note de l'industrie : Qualys WAS était l'un des leaders du GigaOm Radar 2023 pour les tests de sécurité des applications. Les utilisateurs citent sa facilité d'utilisation dans le nuage et l'avantage d'une surveillance continue. En revanche, certains trouvent l'interface utilisateur un peu désuète et la configuration initiale (comme les scripts d'authentification) nécessite une courbe d'apprentissage. Il s'agit néanmoins d'un choix très solide avec le soutien de Qualys.

Rapid7 InsightAppSec

Rapid7 InsightAppSec est une solution DAST alimentée par le cloud qui fait partie de la plateforme Insight de Rapid7. InsightAppSec met l'accent sur la facilité d'utilisation et d'intégration, rendant les tests dynamiques accessibles aux équipes de sécurité et aux développeurs. Il tire parti de l'expertise de Rapid7 (de produits tels que Metasploit et de leurs outils de gestion des vulnérabilités) pour fournir un scanner capable de traiter les applications web modernes, y compris les applications à page unique et les API. En tant que service en nuage, il élimine la nécessité de gérer l'infrastructure du scanner.

Caractéristiques principales :

• Couverture des applications web modernes : InsightAppSec peut tester les applications web traditionnelles ainsi que les SPA construites sur des frameworks comme React ou Angular. Il a la capacité d'exécuter du JavaScript et de crawler du contenu généré dynamiquement. Elle gère également le HTML5 et les modèles web plus récents. Rapid7 souligne qu'il peut tout sécuriser, des formulaires HTML hérités aux apps modernes côté client.
• Plus de 95 types d'attaques : Le scanner comprend plus de 95 types d'attaques dans son répertoire, couvrant des vecteurs communs et complexes. Cela inclut les suspects habituels (SQLi, XSS) mais aussi des choses comme l'injection de CRLF, SSRF, et d'autres failles web moins courantes. Il hiérarchise les résultats en fonction du risque pour vous aider à vous concentrer sur l'essentiel.
• UX simplifiée : InsightAppSec est conçu avec une interface utilisateur conviviale. La mise en place d'un scan est simple - il suffit de fournir une URL, des informations de connexion optionnelles, et c'est parti. L'interface guide les utilisateurs moins expérimentés dans la configuration. Une fois les analyses terminées, les résultats sont expliqués avec des conseils de remédiation et des informations conviviales pour les développeurs. L'application propose également des fonctionnalités telles que la relecture de l'attaque (pour vérifier une découverte en rejouant la requête spécifique qui l'a exposée).
• Analyse parallèle et absence de temps d'arrêt : Étant donné que le système est basé sur le cloud, vous pouvez exécuter plusieurs analyses simultanément sans vous soucier des ressources locales. C'est idéal pour analyser plusieurs applications ou pour travailler en multitâche (Rapid7 indique qu'il est possible d'analyser de nombreuses cibles sans temps d'arrêt). Cette évolutivité est utile pour les agences ou les grandes organisations qui analysent de nombreuses applications web.
• Intégration et écosystème : InsightAppSec s'intègre à la plateforme plus large Rapid7 Insight. Par exemple, vous pouvez envoyer des vulnérabilités à InsightVM (leur gestion des vulnérabilités) ou générer des tickets dans Jira. Il peut également s'intégrer aux pipelines CI et dispose d'une API pour l'automatisation. De plus, si vous utilisez Rapid7 InsightConnect (SOAR), vous pouvez automatiser les actions DAST (comme déclencher un scan lorsqu'une nouvelle application est déployée, etc.)

Le meilleur pour : Les organisations qui veulent un DAST basé sur le cloud avec une interface intuitive et de fortes capacités d'intégration. Si vous êtes déjà un client Rapid7 (utilisant InsightIDR, InsightVM, etc.), l'ajout d'InsightAppSec vous semblera naturel et les données pourront circuler entre les produits. C'est également un bon choix pour les équipes qui n'ont pas d'expert AppSec dédié - l'approche conviviale réduit la barrière des compétences pour exécuter des analyses.

‍Modèle de tarification: SaaS commercial. Rapid7 octroie généralement des licences InsightAppSec par application ou par cible, souvent sous forme de packs. Elle l'associe souvent à ses autres produits pour offrir une solution de sécurité plus globale. Une version d'essai gratuite est disponible et des démonstrations guidées sont proposées. Dans les commentaires, certaines PME mentionnent que le prix est raisonnable pour la valeur, alors qu'une utilisation très importante peut devenir plus onéreuse (ce qui est typique pour SaaS lorsque l'on passe à des centaines d'applications).

Points forts de l'évaluation : "Nous avons utilisé Rapid7 pour nos tests de vulnérabilité et... Ils se sont révélés inestimables en fournissant une solution complète et efficace". Les utilisateurs louent souvent l'assistance de Rapid7 et la qualité générale de la plateforme. L'un des inconvénients potentiels mentionnés est que la correction des bogues dans le produit peut parfois être lente, mais de nouvelles fonctionnalités et améliorations sont régulièrement mises en place.

Tenable.io Web App Scanning

Tenable.io Web App Scanning est l'offre DAST dédiée de Tenable au sein de sa plateforme cloud Tenable.io. Alors que Nessus (abordé plus haut) peut effectuer certains scans Web, Tenable.io WAS est une solution spécialement conçue pour tester dynamiquement les applications Web, et bénéficie d'un moteur et d'une interface plus modernes. Tenable le positionne comme un scanner facile à utiliser mais complet, ce qui intéresse souvent les clients qui utilisent déjà Tenable.io pour la gestion des vulnérabilités.

Caractéristiques principales :

• Plateforme unifiée : Tenable.io WAS cohabite avec les autres services de Tenable (comme Tenable.io Vulnerability Management, Container Security, etc.) de sorte que tous les résultats sont accessibles dans un seul tableau de bord. Pour les équipes de sécurité, cette " fenêtre unique " pour les vulnérabilités de l'infrastructure et du Web est pratique. Vous pouvez voir les vulnérabilités de vos applications Web dans le contexte des vulnérabilités du réseau, suivre les scores de risque des actifs et gérer le tout ensemble.
• Facilité de déploiement : En tant que produit SaaS, vous pouvez lancer une analyse en quelques clics. Tenable.io WAS peut analyser les applications Web externes dès le départ. Pour les applications internes, vous pouvez déployer un scanner Tenable qui effectuera l'analyse et enverra un rapport au cloud. La configuration est simple, et Tenable fournit des modèles pour les analyses rapides et les analyses approfondies.
• Exploration et audit automatisés : Le scanner parcourt automatiquement l'application pour établir un plan du site, puis vérifie chaque page/formulaire qu'il trouve. Il teste les points d'injection et les vulnérabilités les plus courants. Tenable a amélioré le moteur d'analyse pour gérer les applications web modernes (comme le traitement JS). Bien qu'il n'ait pas fait l'objet du même battage marketing que certains concurrents, il couvre en pratique la plupart des vulnérabilités standard et dispose de vérifications spécifiques pour des éléments tels que DOM XSS et les attaques basées sur JSON.
• Résultats rapides et analyses incrémentales : Tenable.io WAS met l'accent sur la rapidité : il peut fournir des résultats exploitables en quelques minutes pour les problèmes courants. Il est également conçu pour une analyse continue - vous pouvez programmer des analyses hebdomadaires ou mensuelles, et il prend en charge l'analyse incrémentale (en testant uniquement le contenu nouveau ou modifié) pour réduire la durée d'analyse lors des exécutions suivantes. Ceci est utile pour les environnements de développement agiles avec des versions fréquentes.
• Intégration et DevOps : Tenable.io dispose d'une API, ce qui vous permet de déclencher des analyses d'applications Web de manière programmatique ou de les intégrer à CI/CD. Il existe également des intégrations permettant d'envoyer les résultats dans des systèmes de billetterie. Si vous utilisez Infrastructure as Code, vous pouvez même créer un environnement de test, l'analyser avec Tenable.io WAS via l'API, puis le détruire - une porte de sécurité entièrement automatisée dans les pipelines CI (certains utilisateurs avancés le font).
• Complémentaire à Nessus : Tenable suggère souvent d'utiliser Nessus et WAS ensemble - Nessus pour le réseau et les vérifications web de base, et WAS pour les tests plus approfondis des applications web. Si vous gérez déjà les analyses Nessus dans Tenable.io, l'ajout de WAS se fait en toute transparence. Les tableaux de bord peuvent afficher des scores de risque combinés, etc. Les analyses de Tenable (avec Tenable Lumin) peuvent alors prioriser les problèmes sur tous les types d'actifs de manière cohérente.

Idéal pour : Ceux qui souhaitent utiliser DAST dans un contexte plus large de gestion des vulnérabilités. Si la gestion des vulnérabilités AppSec et NetSec est gérée par une seule équipe, Tenable.io WAS leur permet d'utiliser un seul ensemble d'outils. Il convient également aux équipes qui souhaitent une solution DAST relativement autonome - il n'est pas nécessaire d'être un gourou de la sécurité Web pour l'utiliser, c'est tout à fait automatisé. Cependant, des applications extrêmement complexes peuvent nécessiter des réglages et, dans ce cas, d'autres outils peuvent offrir un contrôle plus manuel.

‍Modèle de tarification: Tenable.io WAS est basé sur un abonnement, souvent par application ou URL. Tenable peut l'associer à sa licence de plate-forme Tenable.io. Par exemple, vous pouvez obtenir un certain nombre de cibles WAS si vous êtes déjà client de Tenable.io. Son prix est généralement compétitif par rapport à d'autres solutions DAST SaaS pour les entreprises.

Note : Tenable a investi dans WAS pour rester à la hauteur de ses concurrents ; en 2024, ils ont ajouté la prise en charge de choses telles que l'enregistrement plus facile des séquences de connexion et l'amélioration de l'analyse des applications à page unique. Les utilisateurs le trouvent "simple, évolutif et automatisé ", ce qui correspond au message de Tenable de fournir un DAST complet sans trop de difficultés. C'est un bon outil "polyvalent".

Wapiti

Wapiti est un scanner de vulnérabilités web libre et gratuit écrit en Python. Le nom Wapiti vient d'un mot amérindien désignant l'élan - ce qui est tout à fait approprié, car l'élan est agile et puissant dans son domaine. Wapiti fonctionne comme un scanner "boîte noire" : il n'a pas besoin de code source ; il se contente d'analyser votre application web par le biais de requêtes HTTP, à l'instar d'un DAST classique. Il s'agit d'un outil en ligne de commande qui est particulièrement populaire parmi les amateurs de logiciels libres et qui est connu pour être activement maintenu (avec des mises à jour récentes qui ajoutent de nouveaux modules de vulnérabilité).

Caractéristiques principales :

• Approche Black-Box Fuzzing : Wapiti explore l'application web cible pour trouver des URL, des formulaires et des entrées, puis lance des attaques en injectant des charges utiles pour tester les vulnérabilités. Il couvre un large éventail de failles d'injection : Injection SQL (erreur, booléenne, temporelle), injection XPath, scripts intersites (réfléchis et stockés), inclusion de fichiers (locaux et distants), injection de commandes OS, attaques d'entités externes XML (XXE), etc. En gros, s'il y a un champ de saisie, Wapiti essaiera de le casser.
• Modules pour diverses vulnérabilités : Comme indiqué sur son site, les modules de Wapiti gèrent tout, des vulnérabilités web classiques aux contrôles tels que l'injection de CRLF, les redirections ouvertes, le SSRF via un service externe (il peut tester si le SSRF est possible en utilisant un site web Wapiti externe comme capteur), la détection de HTTP PUT (pour voir si WebDAV est activé), et même les contrôles de vulnérabilités telles que Shellshock dans les scripts CGI. Cette étendue est impressionnante pour un outil gratuit.
• Authentification et cadrage : Wapiti prend en charge l'analyse authentifiée par plusieurs méthodes : Basic, Digest, NTLM, et authentification par formulaire (vous pouvez lui fournir des informations d'identification ou un cookie). Il permet également de restreindre la portée - par exemple, vous pouvez lui demander de rester dans un certain domaine ou dossier, ce qui est utile pour éviter d'attaquer des liens tiers ou des sous-domaines dont vous n'êtes pas propriétaire. Vous pouvez également exclure des URL spécifiques si nécessaire.
• Génération de rapports : Il produit des résultats dans plusieurs formats (HTML, XML, JSON, TXT, etc.). Le rapport HTML est pratique pour un examen rapide, tandis que le format JSON est utile si vous souhaitez analyser ou fusionner les résultats de manière programmatique. Les rapports répertorient chaque vulnérabilité trouvée avec des détails tels que la requête HTTP utilisée pour l'exploiter, ce qui est très utile aux développeurs pour la reproduire et la corriger.
• Facilité d'utilisation et d'entretien : Wapiti est facile à installer (disponible via pip) et à exécuter (wapiti -u <url> lance un balayage). Il est assez rapide et vous pouvez ajuster le nombre de requêtes simultanées. Il est important de noter que Wapiti est activement maintenu - la dernière version (à la mi-2024) a ajouté de nouvelles fonctionnalités et vulnérabilités. Les responsables du projet le maintiennent à jour au fur et à mesure de l'apparition de nouveaux exploits (comme les récents CVE), ce qui résout un problème courant où les scanners open-source prennent du retard. Comme il s'agit d'un programme Python, il est également facile de le modifier si vous le souhaitez.

Idéal pour : Les développeurs et les pentesters qui préfèrent les outils open-source et le contrôle en ligne de commande. Wapiti est un choix solide à intégrer dans les scripts ou les pipelines CI pour une pile de sécurité open-source. Il peut nécessiter un peu plus d'efforts pratiques (pas d'interface graphique, installation manuelle), mais la contrepartie est l'absence de coût de licence et une transparence totale sur ce qu'il fait. Il est également léger, de sorte que vous pouvez l'exécuter dans un conteneur Docker ou un travail CI sans avoir besoin de ressources lourdes.

‍Modèle de tarification: Gratuit (GPL v2). Le seul coût est votre temps pour apprendre et éventuellement contribuer à des mises à jour.

L'amour de la communauté : Wapiti n'est peut-être pas aussi célèbre que ZAP, mais les utilisateurs qui le découvrent louent souvent son efficacité. C'est comme un joyau caché pour le fuzzing automatisé des applications web. Comme il n'est pas livré avec une interface graphique, il est moins intimidant à intégrer pour ceux qui sont à l'aise avec le CLI. De plus, ses mises à jour (comme l'ajout de la détection Log4Shell fin 2021) montrent qu'il s'adapte aux événements de sécurité importants. Si vous assemblez une boîte à outils AppSec open-source, Wapiti + ZAP couvrent beaucoup de terrain.

w3af

w3af (Web Application Attack and Audit Framework) est un cadre open-source complet permettant de trouver et d'exploiter les vulnérabilités des applications web. Souvent surnommé "Metasploit pour les applications web", w3af offre des capacités d'analyse et d'exploitation des vulnérabilités en un seul logiciel. Il est écrit en Python et possède des interfaces graphiques et de console. Bien qu'il s'agisse d'un projet plus ancien, c'est toujours l'un des outils de sécurité web open-source les plus complets disponibles.

Caractéristiques principales :

• Système de plugins étendu : w3af fonctionne avec une architecture basée sur des plugins. Il possède des dizaines de plugins d'audit qui testent des vulnérabilités spécifiques (SQLi, XSS, CSRF, débordements de mémoire tampon, etc.), des plugins d'exploration pour découvrir des pages (dont un qui analyse JavaScript pour trouver des URL), et des plugins d'attaque pour tenter d'exploiter les problèmes trouvés. Il est possible d'affiner le choix des plugins à exécuter ou d'utiliser un profil qui en active un certain nombre. Cette modularité signifie que w3af peut être configuré pour des analyses rapides, des audits complets ou des missions axées sur les exploits.
• Analyse et exploitation : Non seulement w3af trouve des vulnérabilités, mais il dispose également d'une composante d'exploitation. Par exemple, s'il trouve une injection SQL, il dispose d'outils pour l'exploiter (comme l'extraction de données, à l'instar de sqlmap). S'il trouve une inclusion de fichier, il peut essayer d'obtenir un shell à distance. Il est donc utile pour les chercheurs en sécurité qui souhaitent aller au-delà de la simple détection et démontrer l'impact.
• Interface graphique et console : Il existe une interface graphique basée sur GTK (bien qu'elle soit un peu désuète) qui fournit un moyen plus convivial de configurer les analyses et de visualiser les résultats. La console est assez puissante et permet des actions de script dans un environnement pseudo-shell (vous pouvez utiliser des commandes pour définir des cibles, des plugins, etc., comme dans la console de Metasploit). Elle s'adresse aussi bien aux débutants qu'aux utilisateurs avancés.
• Combinaison d'analyse statique et dynamique : w3af peut en fait effectuer une analyse statique du code si on lui donne un accès direct (par le biais de ses plugins d'audit de code), mais il s'agit avant tout d'une analyse dynamique. Il dispose également de plugins de grepping qui inspectent les réponses HTTP brutes à la recherche d'éléments tels que les numéros de carte de crédit, les numéros de sécurité sociale, les messages d'erreur - ce qui permet d'obtenir des informations qui ne constituent peut-être pas une vulnérabilité en soi, mais qui ont une incidence sur la sécurité. Cette approche holistique le distingue des scanners qui se concentrent uniquement sur les vulnérabilités directes.
• Open-Source et extensible : Le projet est ouvert sous licence GPL. Bien que le rythme des mises à jour ait ralenti, les connaissances existantes dans ses plugins sont considérables. Comme il s'agit de Python, les utilisateurs peuvent modifier les plugins ou en écrire de nouveaux pour étendre ses capacités. Il existe également une riche documentation (le site w3af docs) et même une API pour le contrôler, bien que la plupart des utilisateurs se serviront de la CLI ou de l'interface graphique.

Idéal pour : Les professionnels de la sécurité et les amateurs qui souhaitent disposer d'une boîte à outils gratuite permettant de faire le lien entre l'analyse et l'exploitation. Il est particulièrement utile dans les scénarios de tests de pénétration - vous pouvez scanner avec w3af pour trouver des problèmes et ensuite les exploiter de manière transparente pour confirmer l'impact. Pour une simple équipe de développement à la recherche d'un scan rapide, w3af peut sembler un peu lourd ou complexe comparé à ZAP ou Wapiti. Mais pour ceux qui sont prêts à investir du temps, il peut être très gratifiant. Modèle de prix : Gratuit, open-source. Pas de version commerciale.

Attention : w3af, étant puissant, peut être potentiellement dangereux - par exemple, ses plugins d'exploitation peuvent altérer les données. Il est préférable de l'utiliser dans des environnements de test/staging ou avec une autorisation explicite en production (et en sélectionnant soigneusement les plugins). Le développeur principal du projet, Andres Riancho, est passé à d'autres activités il y a quelques années (il est connu pour sa contribution à de nombreux outils de sécurité), mais w3af reste un outil incontournable dans de nombreuses boîtes à outils de pirates. Il peut nécessiter un peu de dépannage pour fonctionner sur les systèmes d'exploitation modernes (l'enfer des dépendances parfois), mais une fois qu'il est en place, vous avez un couteau suisse pour la sécurité des applications web.

Après avoir présenté les meilleurs outils individuellement, nous allons maintenant détailler les recommandations en fonction des cas d'utilisation spécifiques. Les besoins varient d'une équipe à l'autre : un développeur peut privilégier la facilité d'intégration, tandis qu'un RSSI d'entreprise peut privilégier l'évolutivité et l'assistance. Les sections ci-dessous proposent des choix adaptés à différents scénarios.

Meilleurs outils DAST pour les développeurs

Public : Les développeurs et les ingénieurs DevOps qui souhaitent détecter rapidement les bogues de sécurité et intégrer les tests dans leur flux de travail. Ces utilisateurs apprécient les outils qui sont faciles à utiliser, qui ne sont pas submergés de faux positifs et qui s'intègrent aux environnements de développement (IDE, CI/CD, etc.). Souvent, ils n'ont pas d'expertise approfondie en matière d'AppSec, de sorte que l'outil doit fournir des conseils et une automatisation.

Lorsque vous choisissez un outil DAST en tant que développeur, tenez compte des éléments suivants :

• Intégration avec CI/CD et IDE : L'outil s'intègre-t-il dans votre pipeline de construction ou fournit-il un plugin IDE ? Les tests de sécurité automatisés en CI permettent de détecter les problèmes avant la fusion. Certaines plateformes (comme la sécurité CI/CD d'Aikido) rendent cette intégration transparente.
• Peu de faux positifs et de bruit : Les développeurs n'ont pas le temps de chasser les fantômes. Les outils qui valident les résultats (par exemple Invicti) ou qui ont une grande précision sont préférables, de sorte que lorsqu'un bogue est signalé, il vaut la peine d'être corrigé.
• Résultats exploitables : Recherchez des scanners qui offrent des conseils de remédiation clairs ou même des exemples de code pour résoudre le problème. Mieux encore, certains outils axés sur le développement fournissent des correctifs automatisés ou des demandes de retrait (AI Autofix d'Aikido, par exemple, peut générer des correctifs pour certains problèmes).
• Rapidité et numérisation à la demande : Dans un environnement de développement, des analyses plus rapides permettent un retour d'information rapide. Les outils capables d'analyser des modifications progressives ou des URL spécifiques (au lieu de l'ensemble de l'application à chaque fois) facilitent l'intégration dans le cycle de développement itératif.
• Coût (pour les particuliers ou les petites équipes) : Les options gratuites ou abordables sont intéressantes, en particulier pour les organisations qui ne disposent pas d'un budget dédié à la sécurité. Les outils ou services open-source avec des niveaux de gratuité conviennent bien ici.

Les meilleurs outils pour les développeurs :

• Sécurité d'Aikido - Tout-en-un convivial pour les développeurs : Aikido est conçu pour les développeurs. Il s'intègre dans les flux de travail du code (vérifications PR, échec du pipeline sur les vulnérabilités élevées) afin que les développeurs obtiennent un retour d'information immédiat. Le modèle "Start for Free" de la plateforme et la facilité d'installation (fonctionnement dans le nuage, pas d'infrastructure à gérer) signifient qu'un développeur peut ajouter DAST à son projet en quelques minutes. Il consolide également les résultats avec SAST, de sorte que vous voyez tout en un seul endroit, ce qui réduit les changements de contexte. Pour un développeur, disposer d'un tableau de bord unique pour visualiser et résoudre les problèmes de sécurité représente un gain de temps considérable. De plus, grâce aux suggestions de correction automatique, même les personnes moins familiarisées avec la sécurité peuvent résoudre les problèmes en toute confiance.
• OWASP ZAP - Open Source et scriptable : ZAP est un excellent choix pour les développeurs car il est gratuit et très flexible. Vous pouvez l'exécuter en mode démon dans le CI, utiliser l'API ZAP pour automatiser les scans, ou même utiliser le ZAP HUD pour tester interactivement votre application pendant le développement. De nombreuses équipes de développement mettent en place des scans ZAP nocturnes de leur environnement de développement et envoient les résultats dans Slack ou Jira pour que les développeurs puissent s'y attaquer le lendemain matin. La courbe d'apprentissage est modérée, mais l'OWASP fournit de nombreux conseils. Et comme il est gratuit, il est facile de l'expérimenter. La communauté ZAP signifie également que si vous êtes bloqué, il vous suffira probablement d'une recherche sur Google pour obtenir de l'aide.
• Burp Suite (Community/Pro) - Adjoint aux tests manuels : Pour l'automatisation pure, Burp n'est pas le premier choix des développeurs, mais l'édition communautaire gratuite est un outil pratique à utiliser pendant le développement. Les développeurs peuvent faire passer le trafic de leur application locale par Burp pour voir ce qui se passe sous le capot. Le scanner de Burp, dans la version Pro, peut être utilisé à la demande pour revérifier des zones spécifiques d'une application (comme "J'ai construit un nouveau login OAuth, laissez-moi scanner juste cette partie"). C'est aussi un outil pédagogique - l'utilisation de Burp permet à un développeur d'en apprendre beaucoup sur la sécurité web. Si le budget le permet, l'analyse automatisée de Burp Pro peut être intégrée dans CI à l'aide de son CLI, offrant ainsi aux développeurs une puissante porte de sécurité.
• StackHawk - DAST intégré CI/CD : (Mention honorable) StackHawk est un outil DAST plus récent qui cible spécifiquement les développeurs et les DevOps. Il s'appuie sur le moteur ZAP, mais il est conçu de manière à être prêt pour les pipelines. Vous définissez les configurations de test dans un fichier YAML, et il fonctionne sans tête dans CI. Bien que StackHawk ne soit pas dans notre liste principale ci-dessus, il vaut la peine d'être mentionné pour les cas d'utilisation des développeurs en raison de son attention particulière à être "CI-friendly". Il dispose également d'un niveau gratuit pour une seule application, ce qui est idéal pour les projets individuels ou les applications open-source.
• Wapiti - Vérifications rapides de la CLI : Pour les développeurs qui aiment les outils en ligne de commande et qui souhaitent peut-être inclure un contrôle de sécurité rapide dans leur compilation, Wapiti est une bonne solution. Vous pouvez lancer wapiti dans le cadre de votre suite de tests (peut-être contre une instance de test locale de l'application). Il n'attrapera pas tout, mais il est rapide et signalera les problèmes évidents. Considérez-le comme un outil d'évaluation de la sécurité dans votre CI : léger et sans interface graphique.

Pourquoi ces outils ? Ces outils mettent l'accent sur la facilité d'intégration, l'immédiateté des résultats et le caractère abordable. Ils permettent aux développeurs de "passer à gauche" en matière de sécurité, en identifiant et en corrigeant les vulnérabilités au cours du développement, bien avant que le code ne soit mis en production. Grâce à eux, les développeurs peuvent améliorer la sécurité de manière itérative, tout comme ils améliorent la qualité du code à l'aide de tests unitaires. L'apprentissage acquis en interagissant avec ces outils (en particulier les outils interactifs tels que ZAP ou Burp) permet également aux développeurs d'acquérir une meilleure connaissance de la sécurité, ce qui constitue un avantage caché mais précieux.

Le tableau ci-dessous compare les outils DAST les mieux adaptés aux développeurs qui ont besoin d'un retour d'information rapide, d'une intégration CI/CD facile et de rapports peu bruyants.

Meilleurs outils DAST pour les entreprises

Public : Les entreprises disposant d'un large portefeuille d'applications web et d'équipes dédiées à la sécurité. Elles ont souvent besoin d'outils capables de s'adapter à des centaines d'applications, de fournir un accès basé sur les rôles, des rapports de conformité et une intégration dans les flux de travail de l'entreprise (systèmes de billetterie, gouvernance, etc.). L'assistance et la fiabilité sont essentielles, et un budget est disponible pour des solutions robustes.

Considérations relatives aux outils DAST d'entreprise :

• Évolutivité et gestion : L'outil doit pouvoir analyser de nombreuses applications (éventuellement simultanément), avec une gestion centralisée des programmes d'analyse, des résultats et des autorisations des utilisateurs. Les consoles d'entreprise ou les environnements multi-utilisateurs sont importants (par exemple, HCL AppScan Enterprise ou la plate-forme Invicti).
• Intégrations d'entreprise : L'intégration avec des systèmes tels que les SIEM, les plateformes GRC, les systèmes de suivi des défauts (Jira, ServiceNow) et la gestion des identités (support SSO) est souvent nécessaire. Il faut également un accès aux API pour une intégration personnalisée dans la chaîne d'outils DevSecOps de l'entreprise.
• Conformité et rapports : Les entreprises doivent souvent produire des documents de conformité. Les outils capables de produire des rapports détaillés pour PCI, SOC2, ISO27001, etc. et de suivre la conformité des politiques dans le temps ajoutent beaucoup de valeur. La possibilité d'étiqueter les actifs (par unité opérationnelle, niveau de risque, etc.) et d'obtenir des analyses (tendances, accords de niveau de service sur l'élimination des vulnérabilités) est utile pour la direction.
• Assistance et formation : Le fait d'avoir un fournisseur qui offre une assistance solide (ingénieurs d'assistance dédiés, services professionnels) et une formation est un facteur important. Les outils d'entreprise sont assortis d'accords de niveau de service pour les questions d'assistance. Pour les outils open source, il s'agit d'une lacune - c'est pourquoi les grandes entreprises se tournent vers des options commerciales malgré leur coût.
• Une couverture complète : Les entreprises ne peuvent pas se permettre de passer à côté de certaines choses. L'outil devrait idéalement couvrir non seulement les vulnérabilités web standard, mais aussi des éléments tels que les tests de logique commerciale, ou fournir des moyens d'étendre les tests. Certaines entreprises utilisent plusieurs outils DAST pour combler les lacunes, mais un seul outil robuste est préférable pour des raisons d'efficacité.

Les meilleurs outils pour l'entreprise :

• Invicti (Netsparker) - Précision et échelle : La plateforme d'Invicti est conçue sur mesure pour les entreprises. Elle offre un support multi-utilisateurs, le marquage des actifs et l'évaluation des risques sur des milliers de scans. Les entreprises apprécient l'analyse basée sur la preuve qui réduit considérablement les faux positifs - ce qui améliore le rapport signal/bruit lorsque vous avez un nombre massif de résultats. Invicti peut également s'intégrer au ticketing de l'entreprise (en assignant automatiquement les problèmes trouvés à la bonne équipe de développement via l'intégration de Jira, par exemple). Son tableau de bord fournit une vue d'ensemble de la posture de sécurité de toutes les applications, que la direction peut utiliser pour des mesures. Pour une entreprise, le coût initial est rentabilisé par une solution mature et peu bruyante qui peut constituer l'épine dorsale de son programme AppSec.
• HCL AppScan (Standard/Enterprise) - La puissance de l'héritage de l'entreprise : De nombreuses grandes organisations (banques, assurances, gouvernement) utilisent AppScan depuis des années (d'IBM à HCL). AppScan Enterprise permet un serveur de gestion centralisé où plusieurs scans AppScan Standard peuvent être orchestrés et les résultats agrégés. Il prend en charge l'accès basé sur les rôles, de sorte que les équipes de développement peuvent se connecter et voir les résultats pour leurs applications uniquement, tandis que les équipes de sécurité ont une vue d'ensemble. Les rapports de conformité sont un atout majeur. En outre, pour les entreprises soucieuses de la sécurité des données, AppScan peut être exécuté entièrement sur site (pas de dépendance au cloud), ce qui est parfois non négociable dans des secteurs tels que la défense ou la santé.
• Micro Focus Fortify WebInspect - Intégration profonde avec le SDLC : Les entreprises qui ont déjà investi dans l'écosystème de Fortify (pour SAST, etc.) trouveront que WebInspect s'intègre naturellement. Les analyses de WebInspect peuvent être publiées dans Fortify SSC, qui agit comme un référentiel centralisé des résultats statiques et dynamiques. Cela permet une corrélation croisée et un suivi unifié des efforts de remédiation. Fortify propose également des produits complémentaires tels que Fortify Application Defender (RASP), qui peut utiliser les résultats de WebInspect pour instrumenter et protéger les applications au moment de l'exécution - une synergie appréciée par les entreprises qui mettent en place leurs défenses. En outre, le fournisseur (aujourd'hui OpenText) propose des services professionnels et des formations certifiées pour WebInspect, ce qui est important pour la montée en puissance des grandes équipes.
• Qualys WAS - Cloud Scale et Asset Discovery : Les grandes entreprises dotées d'une infrastructure distribuée apprécient Qualys pour sa facilité d'utilisation dans le nuage et ses capacités de découverte des actifs. Qualys WAS peut découvrir en permanence de nouvelles applications web dans un environnement (à l'aide d'éléments tels que l'analyse du réseau, l'énumération des noms de domaine, etc.), ce qui est très utile pour les entreprises qui ne disposent pas toujours d'un inventaire complet de leurs ressources web (un problème courant). ), ce qui est très utile pour les entreprises qui ne disposent pas d'un inventaire complet de leurs ressources web (problème courant). Cela vous permet ensuite d'intégrer rapidement les applications découvertes dans l'analyse. L'évolutivité de Qualys est prouvée - certaines entreprises effectuent des dizaines de milliers d'analyses par an sur leur plateforme. L'aspect multi-locataires fonctionne également pour les configurations d'entreprise (par exemple, des unités commerciales distinctes peuvent avoir des vues séparées).
• Tenable.io WAS - Gestion unifiée des risques : Pour les entreprises qui souhaitent unifier les risques liés aux applications et au réseau, l'intégration de WAS par Tenable.io avec la gestion des vulnérabilités est intéressante. Les RSSI peuvent obtenir un score de risque unique pour une application qui prend en compte à la fois ses vulnérabilités web (à partir de WAS) et les vulnérabilités infra-serveur (à partir de Nessus). L'approche par plate-forme simplifie également la gestion des utilisateurs et la création de rapports. Le support de Tenable aux entreprises est solide, et ils aident souvent les gros clients à s'intégrer et à régler les scans pour minimiser les impacts sur les performances (ce qui est important lorsque l'on scanne des applications de production critiques dans l'entreprise).
• Sécurité Aikido - Plateforme DevSecOps d'entreprise : Bien qu'Aikido soit relativement nouveau par rapport à certains acteurs historiques, il offre une valeur ajoutée intéressante pour les entreprises qui cherchent à moderniser l'AppSec. Parce qu'il combine plusieurs outils (SAST, DAST, Cloud config, etc.), il peut réduire la prolifération d'outils dans une entreprise. La plateforme est basée sur le cloud mais offre des options sur site (pour la conformité). Les entreprises bénéficient de fonctionnalités telles que l'intégration SSO, la gestion d'équipe et la capacité à gérer des milliers de projets. L'un des avantages est que les développeurs aiment l'utiliser (en raison de la conception axée sur le développement), ce qui peut augmenter l'adoption dans les entreprises où obtenir l'adhésion des développeurs est la moitié de la bataille. Aikido peut être une bonne solution pour les entreprises qui adoptent DevSecOps au sein de grandes équipes, en veillant à ce que la sécurité soit intégrée à chaque étape (code, construction, déploiement, surveillance) de manière unifiée.

Pourquoi ces solutions ? Ils répondent aux exigences des entreprises en matière d'échelle, de support et d'intégration. Dans les grandes organisations, un outil DAST capable d'analyser 500 applications et de générer un rapport exécutif indiquant "nous avons réduit le nombre de vulnérabilités du Top 10 de l'OWASP de 20 % au cours de ce trimestre" vaut de l'or. Des outils comme Invicti, Qualys, etc., fournissent ce type de mesures et de synthèses. En outre, les entreprises doivent souvent analyser les applications internes derrière les pare-feux - des outils avec des moteurs d'analyse sur site (comme les scanners Qualys ou les installations WebInspect sur site) sont nécessaires, ce que toutes les options ci-dessus fournissent.

‍

‍

Les meilleurs outils DAST pour les startups

Public : Les startups et les petites entreprises disposent souvent d'un budget et d'un personnel limités en matière de sécurité. Elles ont besoin d'outils rentables, faciles à utiliser et qui apportent une valeur ajoutée rapidement. Souvent, l'objectif est d'atteindre un niveau de sécurité de base pour répondre aux préoccupations des clients ou des investisseurs (et peut-être de respecter la conformité s'ils traitent des données sensibles), sans faire dérailler le rythme de développement rapide.

Les besoins clés des startups en matière d'outil DAST :

• Accessibilité financière : Les solutions gratuites ou peu coûteuses, ou les outils avec des niveaux de gratuité qui couvrent les petites applications, sont idéales. Les entreprises en phase de démarrage peuvent également envisager de recourir à des logiciels libres pour éviter les coûts récurrents.
• Simplicité : Il se peut qu'il n'y ait pas d'ingénieur en sécurité dédié, de sorte que les développeurs ou DevOps exécuteront les analyses. L'outil doit être facile à mettre en place (de préférence en mode SaaS pour éviter l'infrastructure) et facile à interpréter.
• Des gains rapides : Les startups bénéficient d'outils qui détectent rapidement les problèmes les plus critiques (par exemple, les erreurs de configuration les plus courantes, les vulnérabilités les plus flagrantes) - il s'agit essentiellement d'une vérification de l'état de santé. Elles n'ont pas forcément besoin de l'analyseur le plus complet ; il suffit souvent d'un outil qui détecte les éléments à haut risque dès le début.
• Intégration au flux de travail des développeurs : Les startups ont souvent un développement moderne et agile. Les outils qui s'intègrent aux actions GitHub ou à d'autres outils similaires peuvent aider à automatiser la sécurité sans processus lourd.
• Évolutivité (pérennité) : Bien qu'il ne s'agisse pas d'une exigence absolue, un outil capable d'évoluer avec eux (plus d'applications, plus d'analyses) est un plus, afin qu'ils n'aient pas à changer d'outil au fur et à mesure qu'ils évoluent. Mais au début, le coût peut l'emporter sur cette exigence.

Les meilleurs outils pour les startups :

• OWASP ZAP - Gratuit et fiable : Pour une startup à court d'argent, il est difficile de faire mieux que la gratuité. ZAP peut être le premier scanner à exécuter sur votre application web. De nombreuses startups utilisent ZAP de manière semi-automatique : par exemple, dans le cadre de leurs constructions nocturnes ou simplement en tant que vérification mensuelle par un développeur. Le fait qu'il s'agisse d'un logiciel libre signifie également qu'en cas de croissance, leur équipe de sécurité peut le personnaliser en profondeur. L'investissement dans l'apprentissage de ZAP continue de porter ses fruits. Avantages : pas de coût direct, grande communauté, bonne efficacité pour les vulnérabilités courantes. Inconvénients : nécessite un certain effort pratique et un apprentissage.
• Sécurité d'Aikido - Free Tier & All-in-One : Aikido offre un plan gratuit pour toujours qui est extrêmement attractif pour les startups. Avec ce plan, une startup peut obtenir non seulement DAST mais aussi SAST et d'autres scanners dans une seule plateforme - c'est beaucoup de valeur sans frais, jusqu'à une certaine utilisation. Pour une jeune entreprise, l'utilisation d'Aikido signifie qu'elle n'a pas à jongler avec de multiples outils ; elle bénéficie d'un renforcement immédiat de la sécurité sur l'ensemble de sa pile. De plus, l'accent mis par Aikido sur l'automatisation et la facilité signifie que même sans spécialiste de la sécurité, les développeurs de la startup peuvent la gérer. Au fur et à mesure que la startup grandit, elle peut évoluer en toute transparence dans le cadre des plans d'Aikido, ce qui constitue une bonne protection pour l'avenir.
• Acunetix (par Invicti) - Option adaptée aux PME : Acunetix est une solution commerciale, mais elle est spécifiquement commercialisée pour les petites organisations et son prix est inférieur à celui des outils d'entreprise. Une startup qui dispose d'un peu de budget et peut-être d'une exigence de conformité pourrait opter pour Acunetix parce qu'il est simple et pris en charge. Il peut être installé localement ou exécuté à partir de leur cloud, et il analysera rapidement l'application et produira un rapport soigné (utile si la startup doit montrer un rapport à un client d'entreprise dans le cadre d'une due diligence). Il s'agit en fait d'une "appliance DAST" qui fonctionne. Certaines startups utilisent une seule licence Acunetix dans leur équipe de développement et lancent des scans occasionnels pour s'assurer qu'il n'y a pas de failles évidentes.
• Nessus Essentials - Scanner de vulnérabilité gratuit : Une startup peut utiliser Nessus Essentials (gratuit pour 16 cibles) pour analyser l'hôte de son application web. Bien que Nessus ne soit pas un testeur d'applications web ciblé, il détectera les problèmes de configuration du serveur web (problèmes SSL, logiciels obsolètes) et certaines vulnérabilités web courantes. Il n'est pas exhaustif pour l'application elle-même, mais il s'agit d'une vérification rapide qui peut s'avérer précieuse. Et si le produit de la startup inclut également des services réseau, Nessus les couvre. Il s'agit essentiellement d'un bon outil de "balayage général" pour l'hygiène de sécurité globale. De nombreuses startups utilisent Nessus parce que la version gratuite est suffisante pour une application web et quelques serveurs.
• Suite Burp Communauté - Apprentissage et exploration manuelle : Si l'équipe fondatrice a un penchant pour la technique, il peut être très instructif d'avoir Burp Community à portée de main pour tester manuellement son application. C'est gratuit, et bien que le scanner soit désactivé dans l'édition communautaire, vous pouvez toujours intercepter le trafic et utiliser l'intrus pour tester certains formulaires. Certains développeurs de startups utilisent Burp pour tester manuellement des fonctionnalités critiques (comme les formulaires de connexion et de paiement). Cette méthode n'est ni automatisée ni évolutive, mais pour une petite application, quelques heures avec Burp peuvent permettre de découvrir des erreurs graves (comme des vérifications d'authentification incorrectes). Cette méthode est rentable, car elle est gratuite et ne demande que du temps.

Pourquoi ces outils ? Ils ne coûtent rien ou s'intègrent facilement dans le budget d'une startup, et leur fonctionnement ne nécessite pas un spécialiste à temps plein. L'objectif d'une startup est d'éviter d'être la proie facile - l'utilisation de ces outils peut permettre de détecter les problèmes les plus flagrants (identifiants par défaut, points d'accès administrateur ouverts, injections SQL, etc. De plus, montrer que vous utilisez des outils reconnus comme OWASP ZAP ou Nessus peut renforcer la confiance lorsque l'inévitable questionnaire de sécurité provient d'un client potentiel.

‍

‍

Meilleurs outils DAST gratuits

Public : Toute personne cherchant à améliorer la sécurité de ses applications web sans dépenser d'argent. Il peut s'agir de développeurs amateurs, d'étudiants, de petites organisations ou même de grandes entreprises qui souhaitent expérimenter avant d'acheter une solution. Dans ce contexte, le terme "gratuit" peut désigner des logiciels entièrement libres ou des versions gratuites de produits commerciaux.

Les options DAST gratuites présentent généralement certaines limites (en termes de fonctionnalités, d'assistance ou de profondeur de balayage), mais elles offrent une valeur incroyable pour les besoins de base.

Critères/caractéristiques des meilleurs outils gratuits :

• Pas de coût, pas de contraintes : Utilisation réellement gratuite (pas seulement une courte période d'essai). Dans l'idéal, il s'agit d'un logiciel libre ou soutenu par la communauté.
• Efficacité : Même s'il est gratuit, l'outil doit trouver un nombre significatif de vulnérabilités. La base de référence couvre les 10 principaux problèmes de l'OWASP.
• Soutien de la communauté : Les outils gratuits s'appuient souvent sur des forums communautaires, de la documentation et des mises à jour. Une communauté dynamique garantit que l'outil reste utile.
• Facilité d'utilisation et courbe d'apprentissage : Certains outils gratuits sont clés en main, tandis que d'autres nécessitent des compétences. Nous en énumérerons plusieurs : certains fonctionnent simplement et d'autres nécessitent une expertise plus poussée (pour ceux qui sont prêts à investir du temps plutôt que de l'argent).

Principaux outils DAST gratuits :

• OWASP ZAP: Il s'agit probablement de l'outil DAST gratuit le plus complet. Comme nous l'avons vu, ZAP peut faire beaucoup, et tout cela gratuitement. C'est effectivement la suggestion à faire lorsque quelqu'un demande "Je n'ai pas de budget, comment puis-je faire un DAST ?". ZAP dispose d'une communauté active et même d'un support formel de l'OWASP. Il est continuellement mis à jour et peut être étendu. Pour une solution gratuite, il n'y a pas mieux que ZAP en termes de capacité et de taille de la communauté.
• Nikto: Entièrement gratuit et ouvert, Nikto se concentre sur les problèmes connus. Il est très facile à exécuter - essentiellement un scan à une commande - ce qui le rend accessible. La valeur de Nikto réside dans sa simplicité : vous ne configurez pas grand-chose, vous l'exécutez et vous obtenez un résultat. Il est idéal pour les audits rapides effectués par des personnes qui ne sont pas nécessairement des experts en sécurité (par exemple, un administrateur système peut exécuter Nikto sur un serveur dans le cadre d'une liste de contrôle). Comme il est basé sur les signatures, il peut manquer des problèmes spécifiques, mais en tant qu'outil gratuit, il constitue un bon filet de sécurité.
• Wapiti: Wapiti est gratuit et open-source, et il est étonnamment puissant, rivalisant avec certains scanners commerciaux dans les tests d'injection. Il est peut-être moins connu du grand public, mais les membres de la communauté de la sécurité open-source le respectent. Pour quelqu'un qui est prêt à utiliser un terminal et éventuellement à écrire des scripts autour de lui, Wapiti fournit gratuitement une énorme capacité d'analyse. Son développement actif signifie qu'il suit le rythme des nouveaux types de vulnérabilités, ce qui n'est pas toujours le cas des outils gratuits.
• w3af: Également gratuit et open-source, w3af est plus complexe mais propose à la fois l'analyse et l'exploitation. Il s'agit d'une alternative gratuite à Burp Suite Pro (en quelque sorte). Cependant, les utilisateurs doivent savoir qu'il n'a pas été très actif ces derniers temps. Néanmoins, pour une solution gratuite, w3af peut creuser en profondeur et même exploiter les problèmes, ce que d'autres ne font pas. Il convient mieux aux utilisateurs ayant quelques connaissances en matière de sécurité et souhaitant disposer d'une boîte à outils unique.
• Arachni: Arachni est gratuit (open-source) et était un poids lourd en son temps. Il fonctionne encore bien dans de nombreux cas. Comme il n'est pas activement maintenu, il faut l'utiliser avec prudence sur les technologies de pointe, mais en tant que scanner gratuit, il est complet sur les technologies web plus anciennes. Si vous avez une application qui n'implique pas les dernières SPA, Arachni peut être très efficace et il a une belle interface de rapport. Pour un coût nul, on obtient un rapport d'analyse de qualité professionnelle.
• Burp Suite Community Edition : Bien que l'analyseur complet ne soit pas activé dans l'édition gratuite, je l'inclus parce qu'il permet l'analyse passive et les tests manuels. C'est gratuit et c'est un excellent outil de formation. De nombreux passionnés de sécurité commencent par utiliser Burp Community pour apprendre comment fonctionnent les vulnérabilités, intercepter le trafic, etc. Si vous passez votre application par Burp Community pendant que vous naviguez, il signalera passivement certains problèmes (comme des en-têtes de sécurité manquants ou des valeurs réfléchies qui pourraient suggérer un XSS). Donc, techniquement, il fait du travail DAST gratuitement, bien que limité.

Remarque : de nombreux acteurs commerciaux proposent des essais gratuits (comme 14 jours d'essai d'Acunetix ou un scan gratuit limité de Qualys, etc. ), mais ce ne sont pas des solutions durables. Je m'en tiens donc aux outils qui sont gratuits à long terme, et non limités dans le temps.

Pourquoi ceux-ci ? Ils couvrent les bases (et plus encore) sans aucune barrière financière. Les outils gratuits sont essentiels pour démocratiser la sécurité - ils permettent à tout un chacun de tester ses applications. Les entreprises qui n'ont pas de budget peuvent tout de même améliorer leur posture de sécurité grâce à ces outils. Il est souvent recommandé de combiner plusieurs outils gratuits, car chacun d'entre eux peut détecter des éléments qui échappent aux autres. Par exemple, exécutez Nikto + ZAP + Wapiti ensemble - si les trois sont d'accord pour dire qu'une application est "propre", vous avez probablement traité les problèmes évidents. Le tout sans dépenser un centime.

Meilleurs outils DAST Open Source

Public : Les passionnés de sécurité, les organisations engagées dans des solutions open-source, ou ceux qui veulent une transparence et un contrôle total sur l'outil. Les outils open source sont également privilégiés par les établissements d'enseignement et par les entreprises dont les règles d'approvisionnement sont strictes et qui préfèrent les logiciels audités par la communauté.

L'expression "open source" recoupe celle de "gratuit", mais nous entendons ici spécifiquement les outils dont le code source est disponible et qui sont généralement maintenus par une communauté (souvent sous l'égide de l'OWASP ou d'organisations similaires). L'avantage est que vous pouvez auditer le code de l'analyseur, le personnaliser et vous assurer qu'il n'y a pas de comportement caché de boîte noire.

Principaux outils DAST à code source ouvert (avec un peu de répétition de ce qui précède) :

• OWASP ZAP: Le champion de l'open source. La source de ZAP est sur GitHub, et il y a de nombreux contributeurs. De nombreuses entreprises ont même forké ZAP pour créer des règles d'analyse personnalisées pour leurs besoins spécifiques. Etant sous la gouvernance de l'OWASP, il a de la crédibilité et un processus de développement ouvert clair. Si vous avez besoin d'un DAST OSS, ZAP est généralement le choix n°1.
• w3af: Entièrement open source (GPL). Un utilisateur peut lire le fonctionnement de chaque plugin, les modifier ou en écrire de nouveaux. C'est très utile pour les chercheurs qui veulent ajouter une vérification pour une nouvelle vulnérabilité de manière globale. C'est comme si l'on disposait des éléments constitutifs d'un scanner que l'on peut réassembler. La nature open source de w3af signifie également que vous pouvez l'intégrer dans des cadres de sécurité open source plus importants.
• Wapiti: Hébergé sur GitHub et activement mis à jour par ses mainteneurs, Wapiti invite les utilisateurs à contribuer et à signaler les bogues. Si vous trouvez que votre application déclenche des faux positifs ou que vous découvrez un nouveau type de vulnérabilité, vous pouvez ajouter des modules à Wapiti. L'open source signifie également que vous pouvez intégrer Wapiti dans d'autres systèmes ouverts (comme l'accrocher à un pipeline CI/CD open source).
• Nikto: L'un des plus anciens scanners web open-source. Sa base de données de signatures est librement modifiable, et les gens contribuent fréquemment à l'ajout de nouvelles vérifications. Si, par exemple, une nouvelle vulnérabilité d'application web dans un framework populaire est découverte, tout le monde peut ajouter un test Nikto pour cette vulnérabilité et le partager. La simplicité du code de Nikto (principalement des scripts Perl) signifie que même les personnes ayant des compétences modestes en matière de codage peuvent l'adapter à leur environnement. En ce sens, Nikto est véritablement piloté par la communauté.
• Arachni: Open source (bien que non maintenu actuellement). Sa base de code était bien écrite et certains l'ont forkée ou en ont réutilisé des parties dans d'autres projets. En tant que source ouverte, il sert également de référence d'apprentissage - les nouveaux développeurs DAST peuvent étudier la conception d'Arachni.
• OWASP ZAP( mention honorable) : Je souligne ce point parce qu'au-delà du cœur de ZAP, le marché des modules complémentaires est plein de contributions open source. Des outils comme le module complémentaire GraphQL Scanner, le module complémentaire SOAP Scanner, etc. sont tous open source. Cet écosystème signifie que si ZAP ne fait pas quelque chose aujourd'hui, un plugin open source pourrait apparaître demain pour combler cette lacune. Aucun outil à code source fermé n'a cette agilité alimentée par une communauté mondiale.

Pourquoi l'open source ? La sécurité est souvent une question de confiance. Avec DAST open-source, vous pouvez inspecter exactement les tests effectués et la manière dont les données sont traitées (ce qui est important si vous analysez des applications sensibles - vous savez que l'outil ne siphonne pas les données, par exemple, parce que vous pouvez voir le code). Cela signifie également que si l'outil ne répond pas parfaitement à vos besoins, vous avez la possibilité de le modifier. Les organisations qui sont prêtes à investir des efforts d'ingénierie plutôt que de l'argent peuvent construire des solutions DAST très personnalisées à partir de ces projets.

Les meilleurs outils DAST pour DevSecOps

Public : Les équipes pratiquant le DevSecOps, c'est-à-dire l'intégration des contrôles de sécurité dans l'intégration continue et les pipelines de livraison continue, avec un haut degré d'automatisation et de collaboration entre le développement, la sécurité et les opérations. Ces équipes veulent des outils qui peuvent fonctionner sans tête, produire des résultats lisibles par une machine, et peut-être des contrôles basés sur des critères de sécurité. Elles privilégient aussi souvent les outils qui peuvent être "déplacés vers la gauche" (utilisés au début par les développeurs) ainsi qu'en continu en post-production.

Facteurs importants pour DevSecOps DAST :

• Intégration CI/CD : L'outil doit disposer d'un CLI ou d'une API REST, et idéalement de plugins pour les systèmes CI les plus courants (Jenkins, GitLab CI, GitHub Actions, Azure DevOps, etc.). Il doit être facile à mettre en œuvre dans le cadre d'un pipeline (les versions conteneurisées sont utiles à cet égard).
• Des résultats faciles à automatiser : Résultats dans des formats tels que JSON ou SARIF qui peuvent être utilisés par d'autres systèmes pour une prise de décision automatisée. Par exemple, interrompre la compilation si de nouvelles vulnérabilités de haute gravité sont trouvées - cela nécessite l'analyse automatique de la sortie du scanner.
• Scans incrémentaux ou rapides : Les analyses DAST complètes peuvent être lentes, ce qui constitue un défi pour l'IC. Les outils qui offrent des modes plus rapides ou qui permettent de cibler des composants spécifiques (peut-être via le marquage de points d'extrémité importants) sont utiles. Une autre approche est l'intégration avec les suites de tests - par exemple, attaquer l'application pendant que les tests d'intégration s'exécutent (certaines configurations avancées le font).
• Flexibilité de l'environnement : Les DevSecOps peuvent créer des environnements de test éphémères (par exemple, en déployant une branche d'une application sur un serveur de test, en l'analysant, puis en la démantelant). Les outils DAST qui peuvent facilement pointer vers des URL dynamiques et gérer des environnements en constante évolution sans beaucoup de configuration manuelle brillent ici.
• Boucles de retour d'information : L'idéal de DevSecOps est d'offrir un retour d'information immédiat aux développeurs. Ainsi, un outil DAST capable de commenter une demande d'extraction, d'ouvrir des tickets automatiquement ou d'envoyer des messages sur le chat avec des résultats favorise cette culture du retour d'information rapide.

Principaux outils / approches pour DevSecOps :

• Sécurité Aikido - Automatisation des pipelines : Aikido a été conçu pour s'intégrer dans les pipelines CI (avec sa fonction d'intégration CI/CD). Vous pouvez configurer les analyses d'Aikido pour qu'elles s'exécutent à chaque fusion ou déploiement. Ses résultats peuvent être configurés pour faire échouer les constructions si les seuils de sévérité sont franchis. Le fait qu'il effectue également des analyses SAST signifie que les développeurs bénéficient d'une double analyse statique et dynamique en CI, le tout géré à partir d'une seule plateforme. De plus, la nature cloud d'Aikido signifie que vous n'avez pas à gérer l'infrastructure d'analyse dans vos runners CI ; il vous suffit de faire appel au service d'Aikido. Cela réduit la friction liée à l'ajout de DAST aux pipelines.
• OWASP ZAP (Dockerized) - Le cheval de bataille de DevOps : ZAP fournit une image Docker officielle et même un script d'analyse de base configurable. Ceci est très utilisé dans DevSecOps. Par exemple, vous pouvez avoir une action GitHub qui exécute owasp/zap-baseline-scan contre un site de test déployé pendant 5 minutes et rapporte les résultats. L'API de ZAP permet également une automatisation personnalisée, et la communauté a écrit des wrappers (comme des scripts Python) qui intègrent ZAP avec CI. Comme il est gratuit, vous pouvez l'utiliser dans autant de pipelines que nécessaire. De nombreux tutoriels existent sur "ZAP dans Jenkins" ou similaire, ce qui indique qu'il s'agit d'un modèle commun.
• StackHawk - Conçu pour l'IC : StackHawk (bien que commercial) est essentiellement DAST pour DevOps. Il s'intègre aux pipelines à l'aide d'une approche de configuration en tant que code. Pour les équipes DevSecOps qui disposent d'un budget suffisant, StackHawk aplanit les difficultés liées à l'utilisation de ZAP en CI (StackHawk est construit sur ZAP mais dispose d'une meilleure interface utilisateur et d'un meilleur support pour les développeurs). Il est intéressant de noter que DevSecOps est exactement son cas d'utilisation cible. Il produit dans des formats adaptés aux CI et la société met l'accent sur le fait que DAST ne ralentit pas les CI (avec des conseils de réglage).
• Invicti/Acunetix - plugins CI : Les ateliers DevSecOps d'entreprise utilisant Invicti ont accès à ses capacités d'intégration. Invicti peut fonctionner en mode headless et dispose de plugins pour Jenkins, etc. Il peut marquer les analyses comme réussies/échec sur la base d'une politique (comme l'absence de vulnérabilités critiques). L'avantage d'Invicti est que vous obtenez une analyse approfondie avec la précision basée sur la preuve, mais le défi est le temps d'exécution - les analyses complètes d'Invicti peuvent être trop lentes pour chaque build. Beaucoup résolvent ce problème en effectuant une analyse complète de nuit et une analyse ciblée rapide sur chaque version (ciblée sur les composants modifiés ou en utilisant des tests de fumée + DAST).
• Burp Suite Enterprise - Intégration de pipeline : Burp Suite Enterprise Edition (différente de Burp Pro) est conçue pour exécuter des analyses selon un calendrier ou les déclencher via CI. Elle dispose d'une API REST et de plugins CI. Une équipe DevSecOps peut l'utiliser pour programmer des analyses après les déploiements et transmettre les résultats à JIRA. Bien qu'il ne soit pas aussi souvent connecté à l'IC que ZAP (en raison de son coût), il est utilisé dans certaines configurations DevSecOps dans des entreprises qui ont standardisé Burp.
• Tenable.io WAS - Crochets cloud : Si votre pipeline peut déployer un environnement de test accessible aux scanners cloud de Tenable, vous pouvez déclencher un scan via l'API et demander les résultats. Certaines équipes DevSecOps procèdent ainsi pour les constructions nocturnes. Ce n'est pas aussi instantané qu'une analyse ZAP locale, mais cela permet de décharger l'analyse sur un service en nuage.

En résumé, l 'automatisation est reine. Les outils qui n'ont pas été conçus pour l'automatisation peuvent toujours être utilisés dans les pipelines (via des scripts créatifs), mais ceux qui reconnaissent DevSecOps avec des fonctionnalités et des intégrations permettront de gagner du temps. Les options ci-dessus sont soit intrinsèquement favorables à l'automatisation (ZAP, Aikido, StackHawk), soit ont évolué pour la prendre en charge en raison de la demande du marché (Invicti, Burp Enterprise).

Les équipes DevSecOps utilisent également souvent plusieurs étapes de DAST : une analyse rapide et légère en CI (pour détecter les éléments évidents en quelques minutes) et une analyse plus approfondie après le déploiement (qui peut prendre plus de temps mais ne bloque pas les développeurs). Les outils choisis doivent soutenir cette stratégie.

Meilleurs outils DAST pour la sécurité des API

Public : Les équipes qui ont spécifiquement besoin de tester les API web (REST, SOAP, GraphQL) pour détecter les vulnérabilités. Il s'agit notamment des développeurs backend, des ingénieurs de plateforme API et des testeurs de sécurité qui se concentrent sur les microservices. Les tests de sécurité des API sont légèrement différents des tests d'interface utilisateur Web - il n'y a pas d'interface de navigateur, vous avez donc besoin d'outils qui peuvent analyser les schémas d'API, gérer les charges utiles JSON/XML et comprendre des éléments tels que les jetons d'authentification et les appels d'API en plusieurs étapes.

Capacités clés pour une DAST axée sur l'API :

• Importation des spécifications de l'API : L'outil doit importer les collections Swagger/OpenAPI ou Postman pour connaître les points de terminaison existants et leurs formats. Cela permet de gagner du temps et de couvrir tous les points de terminaison de l'API, même ceux qui ne sont pas faciles à découvrir.
• Prise en charge de GraphQL : Les API GraphQL sont désormais courantes ; les tester nécessite un traitement spécial (requêtes d'introspection, requêtes imbriquées). Un bon DAST pour API devrait comporter des modules pour GraphQL (par exemple, vérification des vulnérabilités spécifiques à GraphQL telles que les dénis de service par requêtes imbriquées en profondeur).
• Prise en charge de SOAP et des API héritées : Toujours d'actualité dans les entreprises - outils permettant de tester les services SOAP en important les WSDL ou en enregistrant les appels SOAP. La prise en charge d'éléments tels que gRPC peut également être envisagée (bien que la prise en charge de gRPC par DAST soit encore balbutiante ; certains outils convertissent gRPC en tests de type REST via des proxies).
• Authentification et jetons : Les tests d'API doivent gérer les clés d'API, les jetons OAuth, les JWT, etc. L'outil doit permettre de les fournir facilement (peut-être via un fichier de configuration ou un script de connexion) afin de pouvoir tester les points d'extrémité autorisés. Bonus s'il peut également tester la logique d'autorisation, par exemple, IDOR (Insecure Direct Object References) en manipulant les ID.
• Gestion des réponses non HTML : Les API renvoient des données JSON ou XML. L'analyseur ne doit pas s'attendre à des pages HTML ; il doit analyser le JSON et trouver quand même des problèmes (comme XSS dans le contexte JSON, ou des erreurs SQL dans les réponses des API). Certains scanners plus anciens n'examinent que les réponses HTML, ce qui n'est pas suffisant pour les API.
• Sensibilisation à la limitation du débit : Une utilisation trop intensive des API peut déclencher des limites de débit ou même entraîner un blocage de l'IP. Les scanners axés sur les API peuvent inclure des paramètres permettant de respecter les limites de débit ou de les limiter de manière appropriée, afin d'éviter de perturber le service (ce qui est important si l'on teste des API de production).

Top Tools for API Security (DAST) (Outils de pointe pour la sécurité des API) :

• Invicti (et Acunetix) - Découverte et test d'API : Invicti est fort en matière d'analyse d'API. Il peut importer des définitions d'API (REST, SOAP, GraphQL) et dispose de contrôles spécialisés pour celles-ci. Par exemple, il peut détecter les vulnérabilités GraphQL et tester de nombreuses requêtes générées automatiquement. Il gère également bien l'authentification. Si une organisation possède de nombreuses API (microservices), Invicti peut les analyser systématiquement. Acunetix, son frère, partage cette capacité et est plus accessible aux petites équipes.
• Qualys WAS - Prise en charge de l'API et de l'OpenAPI v3 : Qualys WAS annonce spécifiquement qu'il détecte les "dérives par rapport à la spécification OpenAPI", ce qui implique qu'il ne se contente pas de tester les API, mais qu'il trouve également les points d'extrémité non documentés en comparant les points d'extrémité observés à la spécification. Cette fonctionnalité est précieuse pour la sécurité des API, car les points d'extrémité non répertoriés peuvent constituer un angle mort en matière de sécurité. Qualys couvre également les API SOAP et peut être alimenté en WSDL. Il s'agit d'un choix solide pour une entreprise possédant de nombreuses API, d'autant plus qu'il s'intègre à leur plateforme globale.
• OWASP ZAP - Avec des modules complémentaires pour les API : ZAP peut à lui seul brouiller et tester les points d'extrémité JSON, mais il brille vraiment pour les API lorsqu'il est utilisé avec des modules complémentaires. Il existe un module complémentaire OpenAPI pour importer des fichiers Swagger et un module complémentaire GraphQL. Grâce à ces modules, ZAP peut créer automatiquement des requêtes pour chaque opération d'API, puis les analyser activement. Comme il s'agit d'un logiciel libre, c'est l'un des rares moyens gratuits de tester les API en profondeur. Il se peut que vous deviez modifier certaines choses (comme fournir des jetons d'authentification via des scripts), mais il existe de nombreux guides de la communauté.
• Burp Suite - Idéal pour les tests manuels d'API : Le scanner de Burp peut être utilisé sur les API, mais les tests d'API avec Burp impliquent souvent des efforts manuels ou semi-automatiques. Vous pouvez utiliser Burp comme proxy pour le trafic des applications mobiles ou les requêtes Postman afin de capturer les appels d'API, puis utiliser Burp Scanner sur ces derniers. Burp dispose également d'une extension appelée "Upload Scanner" qui peut brouiller les API de téléchargement de fichiers, etc. Pour GraphQL, il existe des extensions Burp pour aider. Ainsi, bien qu'il ne s'agisse pas d'un scanner d'API automatisé prêt à l'emploi, Burp est une plateforme puissante pour les tests d'API si l'on est prêt à la piloter. Les capacités d'analyse de l'édition professionnelle testeront en effet les réponses JSON et autres pour détecter les vulnérabilités, tout comme il le fait pour le HTML.
• Postman + Collections de sécurité - (Augmentation de DAST) : Postman lui-même n'est pas un DAST, mais il existe des collections comme les collections "API Security Audit" que les gens ont créées et qui peuvent agir comme des vérifications DAST rudimentaires (par exemple, en envoyant des chaînes d'injection SQL courantes à chaque point de terminaison). Un développeur soucieux de la sécurité pourrait écrire des tests Postman pour effectuer un contrôle de base de ses points de terminaison d'API. Cette approche est gratuite (Postman a un niveau gratuit) et peut être intégrée dans l'IC via Newman (l'interface de programmation de Postman). Elle n'est pas aussi complète qu'un scanner complet, mais il s'agit d'une approche de plus en plus répandue dans le monde DevSecOps pour les tests de sécurité des API.
• Sécurité d'Aikido - Analyse d'API intégrée : la plateforme Aikido inclut l'analyse d'API où vous pouvez renseigner vos points d'extrémité d'API (ou la laisser les découvrir en même temps qu'une analyse web). Elle prend notamment en charge REST et GraphQL. Pour une équipe qui utilise déjà Aikido pour le web, il est pratique d'avoir l'analyse d'API au même endroit. Il tentera des tests d'accès non autorisé (en répétant des requêtes sans authentification pour voir s'il y a des fuites de données), ce qui est un problème courant dans les API. Cette consolidation signifie moins de changement de contexte - les développeurs voient les vulnérabilités de l'API et du web dans un seul tableau de bord.

Pourquoi cela ? Les points d'extrémité des API contiennent souvent des données sensibles et sont sujets à des problèmes tels que le contournement de l'authentification, l'exposition excessive des données, etc. Les outils DAST traditionnels se concentraient historiquement sur les pages web, mais ceux qui sont énumérés ont suivi la tendance API-first. En les utilisant, vous vous assurez que vos API dorsales sont aussi testées que vos API frontales. Étant donné que de nombreuses brèches impliquent désormais des API (rappelez-vous la fuite de données d'utilisateurs de Facebook via une API, ou les problèmes liés à l'API de T-Mobile), il est essentiel de se concentrer sur la sécurité des API. Les outils capables de simuler une consommation malveillante d'API permettent de découvrir ces failles.

Meilleurs outils DAST pour les applications Web

Public : Cela peut sembler large (puisque la plupart des DAST sont destinés aux applications web), mais nous l'interprétons ici comme des organisations spécifiquement axées sur le test d'applications web traditionnelles (sites web, portails, sites de commerce électronique) - éventuellement avec des interfaces utilisateur riches. Elles veulent les outils les plus performants pour trouver les vulnérabilités des applications web dans ces environnements. Cette catégorie pose essentiellement la question suivante : si votre principale préoccupation est de sécuriser les applications web (avec des navigateurs, des formulaires, des comptes d'utilisateur, etc.), quels sont les outils les plus efficaces dans l'ensemble ?

Aspects importants pour l'analyse des applications web (par opposition aux API ou à d'autres niches) :

• Exploration et couverture : Un scanner d'applications web doit explorer efficacement tous les liens, y compris ceux générés par des scripts ou des événements utilisateur. Les outils dotés de meilleurs algorithmes d'exploration (navigateur sans tête, gestion des SPA) couvriront une plus grande partie de l'application.
• Gestion des sessions : Les applications web ont souvent une connexion et un état complexes (panier d'achat, flux de travail en plusieurs étapes). Les meilleurs outils DAST pour applications web peuvent gérer ces éléments via des macros enregistrées ou des scripts logiques.
• Profondeur de la vulnérabilité : Pour les applications web, des éléments tels que XSS, SQLi, CSRF, l'inclusion de fichiers, etc. sont essentiels. Certains outils ont des vérifications plus complètes que d'autres pour les XSS (réfléchis, stockés, basés sur DOM), par exemple. La capacité d'un outil à détecter les XSS stockés (qui peuvent impliquer la soumission d'une page et le déclenchement d'une autre) peut faire la différence entre les bons et les mauvais outils.
• Traitement des faux positifs : Les outils qui vérifient ou hiérarchisent clairement les possibilités d'exploitation permettent de se concentrer sur les vrais problèmes.
• Contrôles de sécurité côté client : Les applications web modernes peuvent présenter des problèmes tels que l'utilisation non sécurisée du stockage côté client ou des vulnérabilités dans des scripts tiers. Certains outils DAST signalent désormais si votre site charge un script présentant une vulnérabilité connue ou si la politique de sécurité du contenu est absente. Il s'agit de vérifications plus "spécifiques aux applications web" que les vulnérabilités brutes.

Les meilleurs outils pour les applications Web :

• Invicti (Netsparker) : En tant que DAST d'applications web de premier plan, Invicti a une excellente capacité d'exploration et de détection des vulnérabilités sur les applications web typiques. Il est connu pour trouver des XSS et des SQLi de manière très fiable, même dans des scénarios complexes. Sa vérification de problèmes tels que XSS (par exemple, il peut insérer une charge utile sûre et ensuite la détecter comme étant exécutée) donne confiance. Pour sa large couverture et sa profondeur, Invicti est souvent bien noté dans les benchmarks de vulnérabilités web.
• Burp Suite Pro : Pour les tests pratiques d'applications web, Burp Pro est inégalé. Son scanner, combiné à la possibilité de naviguer manuellement dans les parties délicates puis de scanner à nouveau, lui permet de gérer les logiques bizarres des applications web. L'avantage de Burp est que si le crawl automatisé échoue quelque part, un humain peut intervenir, franchir l'obstacle et laisser Burp continuer. Ce modèle de test interactif permet souvent de détecter davantage de problèmes dans les applications complexes. Burp dispose également de nombreuses options de réglage de l'analyse en fonction des performances et de l'exhaustivité, ce qui permet d'optimiser les applications web de grande taille.
• Acunetix : Acunetix s'est toujours présenté comme se concentrant sur les technologies web (y compris de nombreuses vérifications spécifiques aux CMS, WordPress, Drupal, etc.) Pour les sites web typiques, en particulier ceux qui utilisent des plateformes standard, Acunetix se distingue en identifiant les vulnérabilités connues et les mauvaises configurations. Il s'agit d'un scanner web solide et polyvalent qui a tendance à avoir une courbe d'apprentissage plus faible, ce qui signifie que vous pouvez le lancer sur une application web et obtenir de bons résultats sans trop d'ajustements.
• OWASP ZAP: Il est gratuit mais, entre des mains expertes, il peut atteindre le niveau des outils commerciaux pour de nombreuses applications web. L'analyse active de ZAP a une large gamme d'attaques. S'il est bien configuré (avec un contexte comme les jetons de session, etc.), il peut trouver beaucoup de choses. ZAP bénéficie également des règles de la communauté ; par exemple, quelqu'un peut contribuer à un script qui teste spécifiquement une vulnérabilité courante du commerce électronique et tout le monde peut l'utiliser. Pour les organisations qui n'ont pas les moyens d'acheter des outils commerciaux, ZAP est la meilleure solution pour la sécurité des applications web.
• HCL AppScan Standard: Il a une longue expérience de l'analyse des applications web. Il peut être configuré en profondeur pour les applications délicates (comme la personnalisation des chaînes d'injection pour éviter de briser certaines pages, ou la mise en pause entre certaines étapes). Le moteur heuristique d'AppScan trouve parfois des problèmes de logique moins évidents. Pour les évaluations purement web, c'est un outil vétéran utilisé par de nombreux testeurs de sécurité professionnels (en particulier ceux qui sont issus de l'époque d'IBM AppScan). Ils disposent d'une vaste base de connaissances sur les vulnérabilités et leurs manifestations dans les applications web, ce qui se traduit par des cas de test approfondis dans le scanner.

Pourquoi cela ? Ils offrent les meilleures chances de trouver une grande variété de vulnérabilités dans les applications web typiques. Ces outils ont fait leurs preuves en analysant des sites web entiers de bout en bout. Des outils comme Invicti et Burp sont souvent utilisés en tandem : l'un pour l'étendue, l'autre pour la profondeur. Acunetix ou AppScan, dans les mains d'un analyste, fournissent une approche structurée de l'analyse à laquelle de nombreuses équipes de sécurité font confiance pour leurs évaluations régulières des applications web de l'entreprise. ZAP, en tant que logiciel libre, démocratise cette capacité.

En bref, si votre objectif est de trouver le plus grand nombre possible de problèmes de sécurité dans ce portail web, les outils susmentionnés sont parmi les premiers que vous envisagerez.

Meilleurs outils DAST pour les API REST

Public : Il s'agit d'une focalisation plus étroite sur les API RESTful (qui pourrait être considérée comme un sous-ensemble de la sécurité des API ci-dessus, mais ici spécifiquement REST). Il s'agit probablement d'équipes développant des API REST (JSON sur HTTP, conception sans état), y compris des backends d'applications mobiles ou de SPA, qui veulent s'assurer que ces API ne sont pas vulnérables.

Domaines d'intervention de REST API DAST :

• Intégration Swagger/OpenAPI : Très important pour REST. Les outils capables d'ingérer une spécification Swagger pour une API REST peuvent énumérer tous les points de terminaison, méthodes et paramètres attendus, ce qui rend l'analyse plus efficace.
• Vulnes spécifiques à REST : Tester des éléments tels que la mauvaise gestion des verbes HTTP (par exemple, la confusion entre GET et POST), l'absence de limitation de débit et les mauvaises configurations typiques de REST (comme HTTP PUT autorisé là où il ne devrait pas l'être, ou des méthodes qui devraient être idempotentes mais qui ne le sont pas).
• Le flou des paramètres : Les points de terminaison REST contiennent souvent des corps JSON. L'analyseur devrait essayer de tester les paramètres JSON avec des charges utiles d'injection, des objets JSON imbriqués, etc. De même, le test des paramètres de requête dans les URL pour les points de terminaison REST (comme /users?filter=<script>).
• Authentification/Autorisation : De nombreuses API REST utilisent des jetons (jetons porteurs). Les outils doivent gérer l'attachement de ces jetons à chaque requête. De plus, tester l'authZ sur REST (comme changer un ID dans l'URL par l'ID d'un autre utilisateur) est quelque chose que certains outils DAST tentent de faire (bien qu'un vrai test de logique d'autorisation puisse aller au-delà de DAST).
• CSRF dans les API : Beaucoup pensent que les API ne sont pas affectées par CSRF si elles n'utilisent pas de cookies pour l'authentification, mais certaines le font (ou certaines autorisent à la fois les cookies et les jetons). Les scanners pourraient vérifier si les points de terminaison changeant d'état ont des protections CSRF lorsque des cookies sont utilisés, par exemple.

Principaux outils pour l'API REST DAST :

• OWASP ZAP avec le module complémentaire OpenAPI : Pour une API REST pure (disons que vous avez un JSON Swagger), l'utilisation de l'extension OpenAPI de ZAP importera tous les points de terminaison. ZAP peut alors attaquer chacun d'entre eux avec les injections appropriées. Vous pourriez avoir besoin d'écrire un script pour gérer les en-têtes d'authentification, mais le scripting de ZAP rend cela faisable. Comme il s'agit d'un logiciel libre, c'est probablement la première chose que beaucoup essaient sur une API REST parce qu'il est possible de l'automatiser. La communauté a également partagé des exemples de scripts spécifiques à l'analyse d'API.
• Synergie Postman + OWASP ZAP : Une approche libre intéressante consiste à utiliser Postman pour piloter l'authentification et l'utilisation normale de l'API (peut-être via une collection de points d'extrémité), tout en mandatant Postman via ZAP. Ce faisant, ZAP observe l'API et vous pouvez alors lancer un scan actif à partir de ZAP sur les points d'extrémité observés. Cette combinaison permet de tester efficacement les points d'extrémité REST qui nécessitent des séquences spécifiques ou des étapes d'authentification non triviales gérées par les scripts de Postman. De nombreux praticiens utilisent cette méthode parce que Postman est parfait pour atteindre tous les points de terminaison correctement (avec des données correctes), et ZAP peut alors se charger de la partie test de sécurité.
• Invicti/Acunetix: Tous deux offrent un support solide pour REST. Par exemple, ils peuvent prendre un fichier Swagger et effectuer des tests complets, y compris la détection d'éléments tels que Problèmes d'accès aux ressources RESTful (comme tester si GET /users/123 peut récupérer les données d'un autre utilisateur en changeant l'ID, c'est-à-dire en rompant l'autorisation au niveau de l'objet). Ils testent également les problèmes de négociation de contenu (par exemple, si l'API prend en charge l'entrée XML, ils peuvent essayer de passer par XXE) - souvent négligés dans les API REST. Ces produits se tiennent au courant des derniers problèmes de sécurité des API (comme le Top 10 des API de l'OWASP) et intègrent des contrôles en conséquence.
• Burp Suite Pro : Avec Burp, tester les API REST signifie généralement lui envoyer des requêtes (via Repeater ou Spider) et laisser le Scanner faire son travail. Si vous avez une API REST importante, vous pouvez importer un Swagger dans Burp via une extension (il y en a une dans BApp Store) qui créera des requêtes Burp pour chaque opération. Vous pouvez ensuite lancer l'analyseur sur ces requêtes. L'avantage de Burp est que si quelque chose doit être affiné (comme l'ajustement d'un format de paramètre particulier), vous pouvez le faire manuellement et renvoyer la requête. Le contrôle manuel garantit une couverture complète, même s'il demande plus de travail qu'un outil automatisé.
• Wapiti: Wapiti a un support décent pour REST (comme pour toute interface HTTP). Il brouille les charges utiles JSON et les paramètres d'URL. Il peut ne pas analyser un fichier Swagger automatiquement, mais si vous lui fournissez des URL d'entrée ou le laissez explorer une page de documentation, il peut toujours trouver des points de terminaison. Si l'on veut un pipeline entièrement open-source pour l'analyse des API REST, Wapiti combiné à un script pour alimenter les points de terminaison à partir d'un Swagger est une solution viable.
• Tenable.io WAS : La solution de Tenable, encore une fois, peut importer Swagger. Elle testera ensuite chaque point d'extrémité. La documentation explique comment tester les API, notamment en ajoutant des en-têtes personnalisés ou des jetons d'authentification dans les paramètres de l'analyse. Tenable utilise probablement aussi son référentiel de vulnérabilités pour vérifier les mauvaises configurations connues dans les serveurs API. Par exemple, il peut vérifier si votre serveur API a activé la liste des répertoires sur certains chemins ou si des frameworks API vulnérables connus sont détectés par leurs signatures.

Pourquoi ces API ? Les API REST sont omniprésentes (toute application web/mobile moderne en possède une). Les injections dans les API REST peuvent être tout aussi dévastatrices (par exemple, une injection SQL dans un point de terminaison REST est aussi grave qu'une injection dans un formulaire web). Les outils susmentionnés ont prouvé leur capacité à tester REST en particulier. Pour preuve, de nombreux outils s'alignent désormais sur le Top 10 de la sécurité des API de l'OWASP, qui porte essentiellement sur REST. Des outils comme Invicti et Qualys WAS mentionnent explicitement la couverture de ces éléments (comme BOLA - Broken Object Level Authorization - qui est le numéro 1 du Top 10 des API, que certains scanners tentent de détecter par ID fuzzing).

L'utilisation de ces outils sur les API REST permet de détecter des problèmes que l'analyse statique du code ne permettrait pas d'identifier (en particulier des problèmes de configuration ou des erreurs dans le contrôle d'accès). Ils simulent des appels clients réels, ce qui est la façon dont les attaquants abordent les API.

Les meilleurs outils DAST pour les applications mobiles

Public : Lorsque nous parlons d'applications mobiles dans le contexte de DAST, nous nous intéressons principalement aux services dorsaux avec lesquels les applications mobiles communiquent, ainsi qu'aux vues Web ou aux navigateurs intégrés dans l'application mobile. La sécurité binaire pure des applications mobiles (comme la vérification des clés codées en dur dans l'APK) est un domaine différent (SAST mobile peut-être), mais DAST pour les mobiles signifie tester les interfaces côté serveur de l'application mobile et éventuellement la communication réseau. Le public peut être constitué de développeurs mobiles ou de testeurs de sécurité qui s'assurent que l'interaction client-serveur mobile est sécurisée.

Aspects clés :

• Tester les points d'extrémité d'API utilisés par les applications mobiles : De nombreuses applications mobiles utilisent des API REST/GraphQL, ce qui nous ramène à l'analyse des API. Cependant, la différence est que vous n'avez peut-être pas de documentation pour ces API s'il s'agit d'une API interne. L'interception du trafic mobile est donc la première étape.
• Gestion des flux d'authentification : Les applications mobiles peuvent utiliser des flux OAuth ou une authentification personnalisée avec des jetons. Un outil DAST pour mobile doit capturer et réutiliser ces jetons. La méthode la plus simple consiste souvent à passer par l'application mobile et à capturer une session authentifiée.
• Tester les webviews : Certaines applications mobiles sont hybrides ou comportent des composants de type webview. Celles-ci peuvent être testées comme des applications web normales si vous pouvez obtenir les URL. Par exemple, une application bancaire peut avoir une section FAQ qui est essentiellement une vue web d'une page web - qui devrait être analysée pour XSS, etc., car si elle est vulnérable, elle pourrait être un vecteur d'attaque à travers l'application.
• Vérification des protocoles non sécurisés : Un DAST examinant le trafic mobile peut remarquer si l'application appelle une URL HTTP au lieu de HTTPS, ou accepte des certificats SSL non valides (certains outils peuvent tester par MITM avec un certificat non valide pour voir si l'application se connecte quand même).
• Flux de travail et état : Certaines interactions mobiles sont des séquences avec état (ajout d'un article au panier, puis achat). Pour les simuler, il peut être nécessaire de créer un script pour l'application mobile ou de reproduire les appels par le biais d'un script automatisé. Il s'agit d'une tâche complexe, c'est pourquoi il est utile de disposer d'outils capables d'enregistrer et de reproduire de telles séquences.

Top Tools/Methods for Mobile App DAST (Outils/Méthodes de pointe pour la DAST des applications mobiles) :

• Burp Suite - Standard de test mobile : Burp est largement utilisé pour tester les applications mobiles. Vous exécutez le proxy de Burp sur votre PC, configurez l'appareil mobile pour qu'il utilise ce proxy (et installez le certificat CA de Burp sur l'appareil pour que HTTPS puisse être intercepté). Ensuite, lorsque vous utilisez l'application mobile, Burp capture tous les appels API. À partir de là, vous pouvez les analyser et les analyser activement. Burp peut également mettre en évidence si l'application fait quelque chose comme de l'épinglage de certificat (auquel cas vous verrez des échecs de connexion dans Burp). Burp permet d'évaluer de nombreux problèmes spécifiques à la téléphonie mobile (comme une validation incorrecte des certificats) en observant ce que l'on peut intercepter ou manipuler. La capacité de Burp à répéter et à modifier les requêtes est cruciale pour tester la confiance des entrées mobiles côté serveur.
• OWASP ZAP - Mobile Proxy and Scan : De la même manière, ZAP peut utiliser un proxy pour le trafic mobile. Sa mise en place sur l'appareil peut nécessiter un certain effort manuel, mais une fois que c'est fait, vous le traitez comme une analyse web normale des points d'extrémité capturés. ZAP ne dispose pas de fonctionnalités spécifiques aux mobiles, mais son analyse générale du web et des API fonctionne bien pour les backends mobiles. Il est gratuit, ce qui est idéal pour les chercheurs individuels qui testent des applications Android.
• HCL AppScan avec Mobile Analyzer : AppScan Standard possède des fonctions qui facilitent les tests mobiles. Il peut observer le trafic d'une application mobile (si vous exécutez l'application par l'intermédiaire d'un proxy ou d'un émulateur) et exécuter ensuite des tests. IBM (et maintenant HCL) a également proposé AppScan Mobile Analyzer, qui effectue une introspection sur les binaires des applications mobiles et une analyse dynamique. Mais en se concentrant sur DAST, AppScan peut certainement tester les points de terminaison web qu'une application mobile atteint, et offre même un client pour automatiser un émulateur mobile, bien qu'il s'agisse d'une utilisation avancée.
• Sécurité Aikido - Plate-forme AppSec complète (mobile inclus) : Bien qu'Aikido ne soit pas un outil de test mobile à proprement parler, il couvre la sécurité des applications mobiles en analysant les API (grâce à son analyse des API) et en effectuant une analyse statique du code mobile (si l'entreprise dispose de la source). Par exemple, si vous avez un backend mobile, vous pouvez envoyer son URL au DAST d'Aikido et obtenir des résultats. Si vous disposez du code mobile, le SAST d'Aikido peut détecter des éléments tels qu'une génération de nombres aléatoires non sécurisée ou des secrets codés en dur. Cette combinaison est utile pour les équipes mobiles qui veulent une plateforme unique pour le code de leur application et les services web de leur application.
• Postman pour l'API mobile + ZAP : Comme précédemment, si vous pouvez capturer les appels de l'API mobile (via un proxy ou en inversant l'application pour obtenir les points de terminaison), vous pouvez les recréer dans Postman et les tester avec ZAP ou manuellement. Il existe également un projet OWASP appelé MobSF (Mobile Security Framework) qui effectue une analyse dynamique en exécutant un émulateur. MobSF fait principalement de l'analyse statique, mais il vaut la peine d'être mentionné en tant qu'outil de sécurité mobile open-source ; pour DAST, il peut faire du fuzzing d'API de base si vous fournissez des points de terminaison.
• Nessus / Nexpose etc. - vérifications de l'environnement : Bien qu'il ne s'agisse pas d'un test direct de l'application, l'exécution d'une analyse de vulnérabilité sur les serveurs hébergeant le backend mobile ou la vérification des configurations SSL (par exemple, avec Qualys SSL Labs ou Nessus) font souvent partie des tests de l'application mobile. Cela permet de s'assurer que les serveurs avec lesquels l'application communique sont configurés correctement (pas d'anciennes versions TLS, etc.). Je mentionne ceci parce que dans les missions mobiles, des outils comme Nessus complètent souvent le DAST en couvrant les problèmes côté serveur au-delà de la logique de l'application.

Pourquoi ces applications ? Les applications mobiles posent des problèmes particuliers, comme l'épinglage de certificats, qui peuvent entraver la DAST. Mais les approches ci-dessus sont celles que les professionnels de la sécurité utilisent pour pénétrer dans la conversation entre l'application mobile et le serveur. Burp Suite est l'outil de facto pour le pentesting des applications mobiles en raison de sa flexibilité. ZAP peut réaliser la même chose avec un peu plus de configuration, mais sans frais. Ces outils vous permettent de détecter des problèmes tels que : l'API fait-elle confiance aux identifiants fournis par l'utilisateur (ce qui entraîne une exposition des données) ? L'application mobile ne parvient-elle pas à valider le protocole SSL (ce qui permet l'intervention de l'homme du milieu) ? L'application appelle-t-elle des points d'extrémité cachés qui ne sont pas évidents ?

En utilisant DAST sur les backends mobiles, il est possible de simuler ce qu'un attaquant ferait s'il démontait l'application mobile et commençait à envoyer des requêtes d'API élaborées. Il s'agit là d'un point essentiel ; de nombreuses violations mobiles (pensez à la fuite d'API d'Uber ou aux problèmes d'API de Snapchat dans le passé) proviennent de quelqu'un qui a inversé l'application mobile et abusé de l'API. Les outils DAST appliqués de la manière décrite ci-dessus permettent souvent de détecter ces faiblesses avant qu'un attaquant ne le fasse.

Conclusion

En 2025, la sécurité des applications Web exige une approche proactive - les attaquants sondent constamment nos sites Web, nos API et nos applications mobiles à la recherche de faiblesses. Les outils de test dynamique de la sécurité des applications (DAST) sont la pierre angulaire de cette défense proactive, car ils offrent une vue d'ensemble des vulnérabilités de votre application. En simulant dynamiquement des attaques, les outils DAST vous aident à identifier et à corriger des problèmes que les examens statiques du code pourraient négliger, qu'il s'agisse d'injections SQL dans un formulaire oublié ou de serveurs mal configurés acceptant des algorithmes de chiffrement faibles.

Prêt à faire passer la sécurité de vos applications au niveau supérieur ? Démarrez gratuitement avec la plateforme tout-en-un d'Aikido.

‍

TL;DR : Nous lançons Opengrep, un fork de SemgrepCE, en réponse à sa fermeture en open-source.

Nous sommes les initiateurs d'Opengrep. Entrons dans le vif du sujet : Le mois dernier, Semgrep a annoncé des changements majeurs dans son projet OSS - stratégiquement programmés pour un vendredi, bien sûr ;)

Depuis 2017, Semgrep est une pierre angulaire de la communauté de la sécurité open-source, offrant un moteur d'analyse de code et un référentiel de règles parallèlement à son produit SaaS. Mais leurs récents mouvements soulèvent la question : que signifie réellement "ouvert" ?

Les principaux changements incluent le verrouillage des règles contribuées par la communauté sous une licence restrictive et la migration de fonctionnalités critiques telles que le suivi des ignorés, des LOC, des empreintes digitales et des métavariables essentielles hors du projet ouvert.

Ce n'est pas surprenant - Semgrep a discrètement quitté le moteur open-source depuis un certain temps. Le changement de marque de "Semgrep OSS" à "Semgrep Community Edition" semble être le dernier clou du cercueil.

Pourquoi ?

Peut-être la pression des sociétés de capital-risque, qui considèrent que les contributions aux logiciels libres "cannibalisent" le chiffre d'affaires de SaaS, ou la protection contre la concurrence ? Semgrep affirme qu'il s'agit d'empêcher les fournisseurs d'utiliser les règles et le moteur dans des offres SaaS concurrentes. Pourtant, pas plus tard qu'hier, lors de l'annonce de leur "IA", le fondateur a déclaré que "le moteur original de Semgrep devient obsolète".

Quoi qu'il en soit, bien que nous respections l'esprit de compétition, cette répression contre les logiciels libres ne fait pas grand-chose pour arrêter les organisations rivales. Plus que tout, cette décision sape la confiance de la communauté, non seulement dans Semgrep, mais aussi dans l'ensemble des projets open-source.

"Ce type de changement nuit également à tous les projets open-source similaires. Chaque entreprise et chaque développeur doit désormais réfléchir à deux fois avant d'adopter et d'investir dans un projet open-source au cas où le créateur déciderait soudainement de changer la licence"... ou de supprimer la fonctionnalité (Opentofu).

Ce schéma est familier : Le changement de licence d'Elasticsearch a conduit AWS à créer OpenSearch. Le mouvement Opentofu est né après le retrait de Terraform de HashiCorp. Les logiciels libres dirigés par des fournisseurs privilégient souvent les intérêts commerciaux au détriment de la communauté afin d'entrer dans la "cour des grands". Et ça craint.

Nous prenons donc des mesures.

Nous nous sommes unis à dix concurrents directs pour lancer Opengrep - une action coordonnée à l'échelle de l'industrie pour maintenir en vie un grand projet open-source et faire du développement de logiciels sécurisés une norme partagée et neutre pour les fournisseurs.

Je suis accompagné de Nir Valtman (PDG, Arnica), Ali Mesdaq (PDG, Amplify Security), Varun Badhwar (PDG, Endor Labs), Aviram Shmueli (CIO, Jit), Pavel Furman (CTO, Kodem), Liav Caspi (CTO, Legit), Eitan Worcel (PDG, Mobb), et Yoav Alon (CTO, Orca Security).

Que pouvez-vous attendre d'Opengrep ?

Amélioration des performances, déblocage des fonctionnalités réservées aux professionnels, extension du support des langues, migration des fonctionnalités critiques vers le moteur, et nouvelles avancées : compatibilité Windows, analyse croisée des fichiers, la feuille de route est longue.

Ensemble, nous mettons en commun les capitaux engagés et les ressources de développement de l'OCAML pour faire progresser et banaliser les tests statiques de la sécurité des applications.

Car il faut bien l'admettre, il y a des choses plus intéressantes à construire. Trouver est une chose... concentrons-nous sur l'avenir, sur la façon dont nous pouvons trouver et corriger les vulnérabilités de sécurité rapidement et automatiquement. Concentrons-nous sur le fait de ramener les développeurs à la construction.

Vous voulez en savoir plus sur Opengrep ?

Lisez le Manifeste Opengrep. Tirez parti d'Opengrep et contribuez-y dès aujourd'hui.
Pour contribuer ou vous joindre à un sponsor, ouvrez une question sur GitHub.

Pour la communauté et les contributeurs, rejoignez la session ouverte de la feuille de route le 20 février.
Suivez-nous sur X. Linkedin.

"L'avenir de SAST est ouvert" sur Opengrep avec Mackenzie Jackson