42Crunch associe chaque risque de l'OWASP API Security Top 10 (2023) à un contrôle précis dans le cycle Contract → Audit → Scan → Protect, afin que les failles soient détectées avant la mise en production — pas après une violation.
La plateforme de sécurité API de 42Crunch est un ensemble d'outils automatisés qui protègent les API depuis la conception jusqu'à la production : API Audit teste le contrat OpenAPI dès la conception, API Scan teste dynamiquement l'implémentation en cours d'exécution pendant le développement et en CI/CD, et API Protection applique le contrat approuvé comme un micro pare-feu au runtime. Ensemble, ils offrent une couverture continue contre chaque catégorie de l'OWASP API Security Top 10 — et non un audit ponctuel qui devient obsolète dès le lendemain de son exécution.
Un endpoint expose un identifiant d'objet — un ID utilisateur, un ID de commande, un ID d'enregistrement — sans vérifier que l'appelant dispose réellement de l'autorisation d'accéder à cet objet précis. Il suffit de modifier l'ID dans la requête pour se retrouver face aux données de quelqu'un d'autre.
L'autorisation au niveau de l'objet est testée automatiquement dans API Scan, avec des gates CI/CD qui bloquent les API vulnérables avant qu'elles n'atteignent la production.
Des faiblesses dans la façon dont une API vérifie qui l'appelle — absence de limitation de débit sur la connexion, règles de mot de passe trop permissives, émission ou validation de jetons non sécurisée, identifiants qui fuitent dans les journaux — permettant à un attaquant d'usurper un utilisateur légitime ou de contourner complètement l'authentification.
Les contrats OpenAPI sont signalés en cas de schémas d'authentification faibles ou absents ; les scans dynamiques testent avec des jetons et identifiants invalides ; la validation des JWT au runtime suit la RFC 8725.
Même lorsque l'accès à un objet lui-même est correctement vérifié, les propriétés individuelles qu'il contient peuvent ne pas l'être — ce qui permet à un utilisateur de lire des champs qu'il ne devrait pas voir, ou d'écrire dans des champs (comme un rôle ou un solde) qu'il ne devrait jamais pouvoir modifier.
Des schémas de requête/réponse sécurisés sont appliqués dès la conception, réanalysés en continu pour détecter toute dérive, avec un blocage au runtime de tout ce que le contrat ne déclare pas.
Une API qui ne plafonne pas ce qu'un client peut demander — taille de réponse, nombre d'enregistrements, temps d'exécution, opérations concurrentes — peut voir ses coûts s'envoler ou être purement et simplement submergée, que ce soit à la suite d'une attaque délibérée ou d'un usage simplement non maîtrisé.
Les limites de débit et les contraintes de charge utile sont définies dans le contrat OpenAPI et appliquées au runtime, avec des protections au niveau de l'analyseur JSON contre les charges utiles surdimensionnées ou trop complexes.
Des hiérarchies de rôles et de permissions complexes rendent facile de laisser une opération administrative ou privilégiée accessible à des utilisateurs qui ne devraient disposer que d'un accès standard — une faille d'autorisation au niveau de la fonction elle-même, et non des données qu'elle manipule.
Le runtime n'autorise l'exécution que des opérations définies dans le contrat — les opérations non définies et les endpoints inconnus sont bloqués par défaut.
Tous les contrôles techniques peuvent être correctement appliqués, et un processus métier — l'achat d'articles à stock limité, la publication d'avis, l'ouverture de comptes — peut malgré tout être détourné si rien ne limite la façon dont il est invoqué, permettant à l'automatisation de l'exploiter à une vitesse ou une échelle qu'aucun utilisateur réel ne pourrait atteindre.
Des scénarios de test chaotiques sur les flux métier sont exécutés pendant Audit et Scan, réduisant le bruit afin que les outils de surveillance comportementale repèrent plus vite les schémas d'abus.
Une API qui récupère une ressource distante à partir d'une URL fournie par le client — sans valider où cette URL pointe réellement — peut être manipulée pour effectuer des requêtes vers une infrastructure interne ou des services externes non prévus, pour le compte de l'attaquant.
Des tests de scénarios valident le comportement avant la mise en production ; au runtime, chaque entrée fournie par le client est assainie et validée.
De petites failles s'accumulent : fonctionnalités inutiles laissées activées, en-têtes de sécurité manquants, messages d'erreur trop verbeux, CORS trop permissif, composants obsolètes. Prises individuellement mineures, elles élargissent considérablement la surface d'attaque une fois combinées.
La sécurité est intégrée au contrat dès la conception — transport, en-têtes, verbes et types de contenu sont imposés, et validés en continu au runtime.
Les API se multiplient plus vite que la documentation ne peut suivre — anciennes versions, endpoints de préproduction et intégrations non documentées restent accessibles longtemps après que plus personne ne les suit activement, chacune constituant une surface d'attaque bien réelle, en dehors de l'inventaire de l'équipe.
Une découverte continue identifie les API non documentées dans les dépôts de code et au runtime ; les API non documentées et retirées sont bloquées par défaut.
Les développeurs ont tendance à faire davantage confiance aux données renvoyées par des API tierces ou partenaires qu'aux entrées utilisateur — en appliquant une validation plus faible et en suivant les redirections sans les remettre en question — ce qui transforme une faille dans un service que vous ne contrôlez pas en une faille dans celui que vous contrôlez.
Le même standard piloté par le contrat s'applique aux API tierces consommées par votre service — pas seulement à celles que vous publiez.
Couvre également l'OWASP API Security Top 10 : édition 2019, cartographiée de la même manière.
Analyse statique du contrat OpenAPI dès la conception — plus de 300 contrôles automatisés, notés instantanément dans votre IDE.
Tests dynamiques contre l'API en cours d'exécution, avec un trafic réel simulé, directement cartographiés sur l'OWASP API Top 10.
Le contrat approuvé devient la politique d'application au runtime — un modèle de sécurité positif, et non une liste de blocage.
Une liste des dix risques de sécurité API les plus critiques, maintenue par la communauté et publiée par l'OWASP — la référence standard que l'ensemble du secteur AppSec utilise pour prioriser les vulnérabilités des API. 42Crunch suit à la fois les éditions 2023 et 2019.
Chaque catégorie correspond à un contrôle précis réparti entre Audit, Scan et Protection — certaines sont détectées dès la conception dans le contrat, d'autres dynamiquement lors des tests, et d'autres encore appliquées en continu au runtime. Aucune étape ne couvre à elle seule toutes les catégories ; c'est la combinaison des trois qui le permet.
Non — cela vient les compléter. Un WAF ou une passerelle générique inspecte le trafic selon des jeux de règles génériques ; la protection runtime de 42Crunch applique votre contrat OpenAPI spécifique comme modèle de sécurité positif, détectant ce qu'un jeu de règles générique n'est jamais assez précis pour identifier comme anormal.
Automatique. La couverture est générée directement à partir de votre contrat OpenAPI — il n'y a aucun jeu de règles séparé à écrire ou à maintenir manuellement.
Oui. Les résultats sont cartographiés sur les deux éditions, de sorte que les équipes qui reportent encore sur la liste 2019 et celles qui sont passées à 2023 bénéficient toutes deux d'une couverture précise et à jour.
Pointez 42Crunch vers votre contrat OpenAPI et découvrez exactement où vous en êtes sur les dix catégories — sans installation d'agent, sans engagement.