Web et API
Tests de sécurité web et API : le DAST expliqué
Les tests de sécurité web et API, souvent appelés tests dynamiques de sécurité des applications (DAST), envoient des requêtes forgées à une application en fonctionnement et observent ses réponses, afin de trouver des failles comme un contrôle d’accès défaillant, des injections ou des erreurs de configuration. Ils complètent l’analyse du code et des dépendances, et ne doivent être menés que sur des systèmes qui vous appartiennent ou que vous êtes autorisé par écrit à tester.
Offre Free, sans carte bancaire.
Qu’est-ce que le test dynamique de sécurité des applications (DAST) ?
Le test dynamique traite l’application comme une boîte noire, ou comme une boîte grise lorsque le testeur dispose d’identifiants. Un outil ou une personne parcourt le site ou lit la description de l’API, puis envoie des requêtes conçues pour provoquer des défaillances : identifiants modifiés, paramètres inattendus, charges utiles surdimensionnées, jetons absents ou falsifiés. Les constats proviennent du comportement, pas du code source. C’est à la fois la force et la limite de la méthode : elle voit ce que voit un attaquant, y compris les problèmes de déploiement et de configuration, mais elle ne trouve que ce qu’elle parvient à atteindre.
Pour les API, la couverture dépend de la connaissance des points de terminaison. Une description OpenAPI, une collection Postman ou du trafic enregistré permettent à un test d’atteindre des opérations qu’un crawler ne trouverait jamais. Ce sont les tests authentifiés, avec au moins deux comptes de rôles différents, qui révèlent la faille en tête de l’OWASP API Security Top 10 : un utilisateur qui accède aux objets d’un autre utilisateur.
En quoi le DAST diffère-t-il du SAST et de l’analyse des dépendances ?
Les trois méthodes répondent à des questions différentes. L’analyse des dépendances vous dit si les composants que vous livrez sont connus pour être vulnérables. L’analyse statique vous dit si votre propre code contient des schémas dangereux. Le test dynamique vous dit si le système déployé, avec sa configuration, son authentification et son infrastructure, peut réellement être détourné. Un programme mature utilise les trois, et se sert des résultats dynamiques pour confirmer lesquels des constats statiques et de dépendances sont exploitables en pratique.
| Méthode | Ce qu’elle examine | Constats typiques | Angles morts |
|---|---|---|---|
| Analyse des dépendances | Lockfiles, manifestes, SBOM et images de conteneurs | Vulnérabilités connues et paquets malveillants dans les composants tiers | Les failles de votre propre code et de la façon dont l’application est déployée |
| Analyse statique (SAST) | Votre code source, sans l’exécuter | Schémas d’injection, fonctions dangereuses, identifiants codés en dur | La configuration d’exécution et la logique d’autorisation réparties entre plusieurs services |
| Test dynamique (DAST) | Le site web ou l’API en fonctionnement, via le réseau | Contrôle d’accès défaillant, injections, erreurs de configuration, points de terminaison exposés | Les chemins de code que le test ne peut pas atteindre, et la cause racine dans le code |
Pourquoi limiter les tests aux domaines que vous possédez ou êtes autorisé à tester ?
Sur le réseau, un test de sécurité et une attaque se ressemblent ; la différence tient à l’autorisation. Dans l’UE, la directive 2013/40/UE impose aux États membres d’ériger en infraction pénale, au moins lorsqu’il ne s’agit pas de cas mineurs, l’accès illégal à des systèmes d’information et l’atteinte illégale à l’intégrité d’un système commis de manière intentionnelle et « sans droit ». La directive définit cette notion comme un comportement qui n’est pas autorisé par le propriétaire du système ou un autre titulaire de droits sur celui-ci, ou qui n’est pas permis par le droit national. Les législations nationales diffèrent dans le détail, mais la règle pratique est partout la même : pas d’autorisation écrite, pas de test.
L’autorisation a aussi des limites techniques. Un site sur un hébergement mutualisé, derrière un réseau de diffusion de contenu (CDN) ou une passerelle d’API tierce implique d’autres propriétaires dont les conditions peuvent restreindre les tests, et un test qui surcharge un service partagé peut nuire à d’autres clients. Prouver le contrôle d’un domaine, par exemple avec un enregistrement DNS ou un fichier sur le serveur web, est une manière courante pour un service de test de confirmer que le demandeur a le droit de le tester. Conservez l’autorisation, le périmètre, la fenêtre de test et la personne à contacter avec les résultats.
Quelles listes OWASP les tests web et API doivent-ils couvrir ?
L’OWASP Top 10 et l’OWASP API Security Top 10 sont les références habituelles pour délimiter un test. Ce sont des documents de sensibilisation plutôt que des référentiels de test complets, mais ils nomment les catégories de failles qui comptent le plus. Les éditions actuelles sont l’OWASP Top 10:2025 pour les applications web et l’OWASP API Security Top 10 2023 pour les API.
Plusieurs catégories ne se détectent pas par le seul test dynamique. Les défaillances de la chaîne d’approvisionnement logicielle relèvent surtout des dépendances et des builds, et une gestion inadéquate de l’inventaire commence par savoir quelles versions d’API et quels hôtes vous exploitez. C’est là que l’analyse côté code et un inventaire exact comblent le manque.
| Rang | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| 1 | Broken Access Control | Broken Object Level Authorization |
| 2 | Security Misconfiguration | Broken Authentication |
| 3 | Software Supply Chain Failures | Broken Object Property Level Authorization |
| 4 | Cryptographic Failures | Unrestricted Resource Consumption |
| 5 | Injection | Broken Function Level Authorization |
| 6 | Insecure Design | Unrestricted Access to Sensitive Business Flows |
| 7 | Authentication Failures | Server Side Request Forgery |
| 8 | Software or Data Integrity Failures | Security Misconfiguration |
| 9 | Security Logging and Alerting Failures | Improper Inventory Management |
| 10 | Mishandling of Exceptional Conditions | Unsafe Consumption of APIs |
Quelle place pour les tests web et API dans le CRA et NIS2 ?
Au sens du règlement sur la cyberrésilience (Cyber Resilience Act, CRA), un produit comportant des éléments numériques inclut ses solutions de traitement de données à distance : un traitement de données à distance conçu et développé par le fabricant ou sous sa responsabilité, sans lequel le produit ne pourrait pas exécuter l’une de ses fonctions. Les considérants du CRA donnent l’exemple d’une application mobile qui a besoin d’une API fournie par le fabricant ; cette API relève du champ d’application, contrairement aux sites internet qui ne supportent pas la fonctionnalité d’un produit. L’annexe I, partie II, exige de soumettre régulièrement le produit à des tests et examens de sécurité efficaces, ce qui, pour un produit doté d’un backend cloud, peut raisonnablement inclure le test de son API.
Les logiciels proposés uniquement en tant que service ne relèvent pas du CRA ; ses considérants renvoient à la directive NIS 2 (SRI 2) pour les services d’informatique en nuage comme le logiciel en tant que service (SaaS). L’article 21, paragraphe 2, point e), de NIS2 exige des entités essentielles et importantes la sécurité de l’acquisition, du développement et de la maintenance de leurs systèmes, y compris le traitement et la divulgation des vulnérabilités. Pour certains fournisseurs de services numériques, le règlement d’exécution (UE) 2024/2690 ajoute une politique documentée en matière de tests de sécurité, des tests dont la nécessité, la portée, la fréquence et le type découlent de l’évaluation des risques, et la consignation du type, de la portée, du moment et des résultats de chaque test.
Disponible aujourd’hui dans KROMSE
KROMSE ne teste pas encore les sites web ni les API en fonctionnement, mais il contrôle le code, les dépendances et les images de conteneurs qui se trouvent derrière.
- Contrôle des dépendances auprès d’OSV.dev pour les lockfiles et les manifestes de votre site ou de votre API, dont npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler et .NET.
- Analyse du code source pour 11 langages, dont JavaScript, TypeScript, Python, Java, Go et C#, ainsi que l’import de vos propres résultats SARIF 2.1.0.
- Détection de secrets au commit analysé ; les valeurs des secrets sont masquées et jamais stockées.
- Détection des erreurs de configuration dans les fichiers Terraform et les Dockerfiles.
- Images de conteneurs d’un registre accessible depuis Internet, analysées à la recherche de vulnérabilités, d’erreurs de configuration et de secrets.
- Les paquets répertoriés dans la base OpenSSF Malicious Packages sont signalés comme critiques, avec leur suppression pour remède.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (décembre)Tests de sites web et d’API. KROMSE recherchera des vulnérabilités dans les sites web et les API, uniquement sur les domaines dont vous aurez vérifié que vous les contrôlez.
- À venir · T4 2026 (décembre)Surveillance selon votre calendrier, avec des agents IA. Les nouvelles analyses s’exécuteront selon un calendrier que vous définirez, avec des agents IA qui surveilleront les nouveaux avis de sécurité, trieront ceux qui s’appliquent, proposeront des correctifs et prépareront le rapport pour votre revue.
Questions fréquentes
KROMSE teste-t-il les sites web et les API ?
Pas encore. KROMSE ne mène pas aujourd’hui de tests dynamiques contre des sites web ou des API. Il contrôle ce qui se trouve derrière : dépendances, code source dans 11 langages, secrets commités, erreurs de configuration Terraform et Dockerfile, et images de conteneurs. Les tests de sécurité de sites web et d’API sur des domaines dont vous avez prouvé le contrôle figurent dans la feuille de route, et cette page évoluera lorsqu’ils seront disponibles.
Est-il légal d’analyser un site web qui ne m’appartient pas ?
En règle générale, pas sans autorisation. La directive 2013/40/UE impose aux États membres de l’UE d’ériger en infraction pénale l’accès illégal à des systèmes d’information et l’atteinte à leur intégrité commis de manière intentionnelle et sans droit, c’est-à-dire sans l’autorisation du propriétaire ou d’un autre titulaire de droits, au moins lorsqu’il ne s’agit pas de cas mineurs. Les législations nationales ajoutent leurs propres règles. Ne testez que des systèmes qui vous appartiennent ou que vous avez l’autorisation écrite de tester, et respectez les conditions de tout hébergeur, CDN ou fournisseur d’API concerné.
Quelle est la différence entre le DAST et un test d’intrusion ?
Le DAST est généralement automatisé : un outil envoie de nombreuses requêtes et signale les comportements qui correspondent à des schémas de failles connus. Un test d’intrusion est mené par une personne qui enchaîne les constats, teste la logique métier et évalue l’impact, souvent en s’aidant d’outils DAST. Les tests automatisés conviennent aux contrôles fréquents et reproductibles ; un test d’intrusion convient aux versions majeures, aux changements importants et aux systèmes à haut risque.
Le CRA impose-t-il des tests de sécurité de l’API de mon produit ?
Le CRA ne prescrit pas de méthode de test. L’annexe I, partie II, exige des tests et examens de sécurité réguliers et efficaces du produit, et un produit inclut ses solutions de traitement de données à distance, comme une API sans laquelle votre application ne peut pas fonctionner. Choisissez les méthodes que votre évaluation des risques justifie, et conservez le périmètre, la méthode et les résultats des tests dans votre documentation technique.
Quelle liste OWASP utiliser pour les API ?
Utilisez l’OWASP API Security Top 10, dont l’édition actuelle date de 2023. Elle se concentre sur des failles propres aux API, comme Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption et Improper Inventory Management, que les listes orientées web couvrent moins directement. Utilisez-la avec l’OWASP Top 10:2025 pour le front-end web.