Votre IA est-elle conforme ? Inscrivez-vous dès aujourd'hui

Sécurité des API 101 : Guide de stratégie et des fondamentaux de la sécurité des API

Les API sont au cœur des initiatives d'innovation numérique d'aujourd'hui et sont devenues le vecteur d'attaque numéro un pour les applications. Découvrez ce qu'est la sécurité des API, pourquoi elle est si importante et ce que vous pouvez faire pour protéger vos API contre les menaces modernes.

Qu'est-ce que la sécurité des API ?

Les interfaces de programmation d'applications (API) sont les éléments constitutifs des applications modernes. Considérez-les comme les portes d'entrée du monde numérique. Elles maintiennent tout le monde connecté aux données et services vitaux, permettent toutes sortes d'opérations commerciales critiques et rendent la transformation numérique possible.

Alors que le nombre d'API continue de croître et que les organisations du monde entier s'appuient de plus en plus sur elles pour mener à bien leurs initiatives commerciales critiques, elles sont devenues une cible privilégiée pour les attaquants. Notre Rapport sur l'état de la sécurité des API T1 2023 montre que le nombre d'attaquants uniques a augmenté de 400 % sur une période de six mois. Et pourtant, 30 % des personnes interrogées n'ont toujours pas de stratégie de sécurité des API en place.

L'Open Web Application Security Project (OWASP) définit la sécurité des API comme l'ensemble des stratégies et solutions visant à comprendre et à atténuer les vulnérabilités et les risques de sécurité uniques des API — qui sont nombreux.

Poursuivez votre lecture pour comprendre pourquoi la sécurité des API est devenue une préoccupation essentielle pour les organisations d'aujourd'hui et en quoi elle diffère de la sécurité des applications.

Pourquoi la sécurité des API est-elle importante ?

Les API sont devenues un vecteur d'attaque principal pour les cybercriminels, les acteurs malveillants ayant compris à quel point il est lucratif de cibler les API qui connectent les services numériques et les données sensibles d'aujourd'hui. En fait, selon le Rapport sur l'état de la sécurité des API T1 2023, 94 % des entreprises ont rencontré des problèmes de sécurité des API dans leurs API de production au cours de la dernière année. En 2017, le cabinet d'analystes Gartner avait prédit que d'ici 2022, les API deviendraient le principal vecteur d'attaque pour les cybercriminels, et cette prédiction s'est avérée exacte. Les attaques d'API ayant fait la une des journaux du monde entier ces dernières années, Gartner a inclus la sécurité des API dans son architecture de référence de sécurité en 2022, reconnaissant ainsi le besoin d'outils et de méthodes dédiés à la sécurité des API.

Alors…

D'ici 2022, les abus d'API passeront d'un vecteur d'attaque peu fréquent au plus fréquent, entraînant des violations de données pour les applications web d'entreprise. »

20 novembre 2017
« Prévisions 2018 : Protection de l'infrastructure »
—Hypothèse de planification stratégique

…et maintenant

À l'approche de 2022, cette prédiction pourrait être considérée comme « manquée » — mais seulement parce que nous avons sous-estimé la forte augmentation des attaques contre les API. »

6 décembre 2021
« Prévisions 2022 : Les API exigent une sécurité et une gestion améliorées »

GartnerGartner

L'importance cruciale de la sécurité des API devient également de plus en plus évidente pour les hauts responsables des organisations actuelles. En fait, près de la moitié (48 %) des répondants à notre enquête sur l'état de la sécurité des API ont indiqué que la sécurité des API est désormais un sujet de discussion au niveau de la direction générale. Cette constatation est également étayée par les résultats d'une enquête mondiale menée par la société de recherche indépendante Global Surveyz pour le compte de Salt Security, où la majorité (78 %) des RSSI mondiaux ont déclaré que la sécurité des API est une priorité plus élevée aujourd'hui qu'il y a deux ans, et 95 % ont affirmé que la sécurité des API sera une priorité absolue au cours des deux prochaines années.

Bien que les mesures de sécurité traditionnelles, telles que les passerelles API et les pare-feu d'applications web (WAF), puissent apporter de la valeur à la pile de sécurité d'une organisation, elles ne peuvent pas suivre le rythme des méthodes d'attaque API de plus en plus sophistiquées d'aujourd'hui. En fait, elles n'empêchent pas les attaquants de voler des données sensibles, d'affecter l'expérience utilisateur ou de causer d'autres dommages. Pour prévenir et atténuer les attaques API, vous avez besoin d'une stratégie et d'une technologie de sécurité spécialement conçues pour les API.

Les attaques ont changé et sont faciles à manquer

Les acteurs malveillants ciblant les API ont dépassé les attaques traditionnelles « uniques et rapides » telles que l'injection SQL et le XSS. Leur objectif est désormais de trouver des vulnérabilités dans la logique métier des API. Vos API sont uniques, les attaques doivent donc l'être aussi. Il faut aux attaquants des jours, des semaines, voire des mois pour sonder et apprendre vos API, et ils utilisent des techniques « lentes et discrètes » qui passent inaperçues des outils de sécurité traditionnels.

Par le passé :

Attaques uniques et rapides
Appel API unique – secondes à minutes
Attaques connues – SQLi, XSS, etc.

Aujourd'hui :

Attaques lentes et discrètes
Séquence d'appels API – jours à semaines
Attaques de logique métier – nécessite un contexte

Les différents types de sécurité des API : des API REST à SOAP et GraphQL

La sécurité des API REST, la sécurité SOAP et la sécurité GraphQL jouent toutes un rôle important pour assurer la protection des API et des applications web. Chacune de ces technologies a une approche différente de la sécurité, ce qui nécessite des considérations de sécurité spécifiques.

Sécurité des API REST

REST signifie Representational State Transfer et est un style architectural couramment utilisé dans les services web. Il repose sur des méthodes HTTP standard telles que GET, POST, PUT, DELETE et utilise des URL pour identifier les ressources. Les API REST présentent leur propre ensemble de considérations de sécurité, telles que :

  • Mécanismes d'authentification — Les API REST utilisent souvent des mécanismes d'authentification tels que les clés API, les jetons OAuth ou les jetons Web JSON (JWT) pour vérifier l'identité des clients et accorder l'accès aux ressources.
  • Mécanismes d'autorisation : Une fois qu'un utilisateur est authentifié, les API REST utilisent des mécanismes d'autorisation pour contrôler les ressources auxquelles il peut accéder.
  • Limitation du débit : Mettez en œuvre la limitation du débit pour restreindre le nombre de requêtes qu'un client peut effectuer dans un laps de temps donné, afin de prévenir les abus et les attaques DoS.
  • Validation des entrées : Celle-ci doit être appliquée pour prévenir les vulnérabilités de sécurité courantes telles que l'injection SQL et les attaques par script intersite (XSS).
  • Chiffrement HTTPS : Le chiffrement des données transmises entre le client et le serveur est essentiel dans les API REST. Le chiffrement HTTPS est utilisé pour empêcher toute interception non autorisée.
  • Partage de ressources inter-origines (CORS) : Les en-têtes CORS doivent être utilisés dans l'architecture REST pour contrôler quels domaines peuvent accéder à l'API concernée.

Pour protéger efficacement les API REST, tous ces aspects doivent être pris en compte, en plus d'autres bonnes pratiques de sécurité des API REST.

Sécurité SOAP

SOAP (Simple Object Access Protocol) est un protocole utilisé pour échanger des informations dans les services web. Il utilise généralement le XML et s'appuie sur d'autres protocoles web tels que HTTP, SMTP et TCP. Il existe également des considérations de sécurité importantes pour SOAP :

  • Chiffrement des données sensibles : Les données sensibles contenues dans les messages SOAP doivent être chiffrées pour garantir leur confidentialité pendant le transit.
  • Validation XML : La validation du XML par rapport à un schéma prédéfini aide à prévenir les injections XML et les attaques associées.
  • Norme WS-Security : SOAP propose cette norme de sécurité pour la sécurisation des messages, qui inclut des fonctionnalités telles que l'intégrité des messages, la confidentialité, l'authentification et l'autorisation.
  • Sécurité HTTPS : Similairement aux API REST, les messages SOAP doivent être transmis via un chiffrement HTTPS pour sécuriser les données en transit.
  • Signatures numériques : Les signatures numériques doivent être utilisées chaque fois que possible pour évaluer l'intégrité et la légitimité des messages SOAP.

Sécurité GraphQL

GraphQL est un langage de requête pour les API et un environnement d'exécution pour ces requêtes avec un système backend. Contrairement à REST, qui expose plusieurs points d'accès API pour différentes ressources, GraphQL utilise un point d'accès unique pour toutes les requêtes. Voici quelques-unes des considérations de sécurité les plus importantes pour GraphQL :

  • Authentification et autorisation : Les API GraphQL doivent implémenter des mécanismes d'authentification et d'autorisation pour contrôler l'accès aux diverses requêtes et mutations. Ces dernières années, des acteurs malveillants sont connus pour exploiter les vulnérabilités d'autorisation GraphQL avec succès pour exécuter des attaques d'API.
  • Limitation du débit : L'application d'une limitation du débit est essentielle pour contrôler le nombre de requêtes GraphQL qu'un client peut exécuter à un moment donné.
  • Validation des entrées : La validation et la désinfection des entrées utilisateur dans GraphQL peuvent aider à prévenir les vulnérabilités de sécurité courantes.
  • Limites de profondeur des requêtes : Il est impératif de définir des limites à la profondeur des requêtes GraphQL afin d'éviter les requêtes complexes et gourmandes en ressources qui pourraient entraîner des attaques par déni de service (DoS).

En fin de compte, la sécurité de toute API, qu'elle soit REST, SOAP ou GraphQL, dépend d'une combinaison de bonnes pratiques couvrant les mécanismes d'authentification et d'autorisation, la validation des données et l'utilisation de protocoles de communication sécurisés. Une stratégie de sécurité API robuste, qui englobe la découverte, la protection en temps réel et les pratiques de "shift-left", est essentielle pour protéger les API contre les menaces émergentes.

Salt — sécurité API complète pour une protection totale

La protection des API Salt Security couvre l'intégralité du cycle de vie des API, y compris la découverte, la protection contre les menaces et la remédiation.

Quels sont les types d'attaques d'API les plus courants ?

La première étape pour protéger efficacement les API est de comprendre pourquoi les attaques actuelles sont différentes. Les attaques d'API les plus courantes aujourd'hui peuvent être réparties en quatre catégories :

Manque de visibilité et de gouvernance

Dans ce type d'attaque, les attaquants tirent parti d'API qui sont soit complètement inconnues d'une organisation — API fantômes ou zombies — soit d'API dont la posture de sécurité n'est pas visible, comme les API non gérées ou tierces.

Abus et mauvaise utilisation des API

Pour exécuter ce type d'attaque, un acteur malveillant utilisera une API exactement telle qu'elle a été conçue, mais exploitera les résultats de manière involontaire et malveillante en exploitant des failles de conception ou de développement qui permettent des résultats malveillants, telles que l'exfiltration de données.

Exploitation des failles de la logique métier

Dans une attaque basée sur la logique métier, les pirates utiliseront des techniques de reconnaissance au fil du temps pour débusquer les vulnérabilités dans la logique métier unique de chaque API. Pendant la phase de reconnaissance, qui peut durer des jours, des semaines, voire des mois, les attaquants recherchent des zones à explorer, telles que l'obtention d'un accès non autorisé à des données ou à des fonctionnalités au sein de l'API.

Identifiants volés et ingénierie sociale

Ce type de menace se manifeste lorsqu'un acteur malveillant utilise des techniques d'ingénierie sociale pour accéder à des clés API privilégiées. Cela leur permet de voler des identifiants et d'utiliser l'API comme s'ils étaient un utilisateur ou un administrateur légitime et authentifié. Selon le rapport sur l'état de la sécurité des API du T1 2023, au cours de la dernière année, 78 % des attaques provenaient d'utilisateurs apparemment légitimes qui avaient obtenu l'authentification appropriée de manière malveillante.

Top 10 de la sécurité des API OWASP

Pour aider l'industrie de la sécurité des API à mieux comprendre les attaques API les plus courantes, l'Open Web Application Security Project (OWASP) a publié sa toute première liste des 10 principales vulnérabilités de sécurité des API en 2019. La liste a été mise à jour en 2023 et répertorie les dix vulnérabilités API les plus importantes. Parmi celles-ci, les plus courantes sont :

API1:2023 autorisation au niveau de l'objet défaillante

L'autorisation au niveau de l'objet défaillante (BOLA) représente environ 40 % des attaques d'API et constitue la menace API la plus courante.

Les API exposant fréquemment des points d'accès (endpoints) qui gèrent les identifiants d'objets, cela crée une vaste surface d'attaque potentielle. L'autorisation au niveau de l'objet est une méthode de contrôle d'accès généralement implémentée au niveau du code pour vérifier la capacité d'un utilisateur à accéder à un certain objet. Les applications modernes utilisent une variété de systèmes d'autorisation et de contrôle d'accès complexes et omniprésents. Les développeurs négligent fréquemment d'appliquer ces vérifications avant d'accéder à un objet, même lorsqu'une application comprend une infrastructure robuste pour les vérifications d'autorisation. Les attaquants peuvent facilement exploiter les points d'accès (endpoints) d'API vulnérables à une autorisation au niveau de l'objet défaillante en manipulant l'identifiant d'un objet envoyé dans une requête API. Les failles d'autorisation BOLA peuvent entraîner l'exfiltration de données ainsi que la visualisation, la modification ou la destruction non autorisées de données. En fin de compte, BOLA peut conduire à une prise de contrôle complète du compte (ATO).

API2:2023 authentification utilisateur défaillante

Les attaquants peuvent facilement cibler les processus d'authentification, surtout s'ils sont entièrement exposés ou accessibles au public. La deuxième vulnérabilité la plus fréquente signalée par l'OWASP est l'authentification utilisateur défaillante, ce qui permet aux attaquants d'utiliser le bourrage d'identifiants (credential stuffing), les jetons d'authentification volés et les attaques par force brute pour obtenir un accès non autorisé aux applications. Les attaquants peuvent alors contrôler les comptes des utilisateurs, obtenir un accès illégal aux données d'autres utilisateurs et effectuer des transactions non autorisées. Des problèmes technologiques, tels qu'une complexité de mot de passe insuffisante, des critères de verrouillage de compte manquants, des durées de rotation excessivement longues pour les mots de passe et les certificats, ou l'utilisation de clés API comme seule méthode d'authentification, peuvent entraîner une authentification défaillante dans les API.

Les attaquants qui parviennent à exploiter les faiblesses des procédures d'authentification peuvent accéder aux données d'un autre utilisateur sans autorisation et effectuer des transactions illicites en utilisant le compte de cet utilisateur.

API3:2023 autorisation au niveau des propriétés d'objet défaillante

L'autorisation au niveau des propriétés d'objet défaillante regroupe les attaques qui se produisent en obtenant un accès non autorisé à des informations sensibles par le biais d'une exposition excessive de données (précédemment classée numéro 3 dans le Top 10 de la sécurité des API OWASP 2019) ou d'une affectation en masse (précédemment à la sixième place de la liste 2019). Les deux techniques sont basées sur la manipulation des points d'accès (endpoints) de l'API pour obtenir l'accès à des données sensibles.

La principale raison d'introduire cette nouvelle menace sur la liste est que, même si une API peut appliquer des mesures de sécurité d'autorisation au niveau de l'objet suffisantes, cela pourrait ne pas être suffisant pour la protéger. Une autorisation plus spécifique couvrant les objets et leurs caractéristiques est souvent requise. Les différents niveaux d'accès au sein d'un objet API doivent également être pris en compte, car un objet API possède souvent une propriété publique et une propriété privée.

API4:2023 consommation de ressources illimitée

La vulnérabilité de consommation de ressources illimitée a remplacé l'ancienne vulnérabilité numéro 4 du Top 10 de la sécurité des API OWASP, le manque de ressources et de limitation de débit. Cependant, bien que le nom ait changé, cette vulnérabilité reste globalement la même.

Les ressources, telles que le réseau, le CPU, la mémoire et le stockage, sont consommées par les appels API. L'entrée de l'utilisateur et la logique métier du point d'accès ont un impact significatif sur le nombre de ressources nécessaires pour satisfaire une requête. La taille ou la quantité de ressources qu'un client ou un utilisateur peut demander peut ne pas être nécessairement limitée par les API. Cela a non seulement le potentiel d'affecter négativement les performances du serveur API et de provoquer un déni de service (DoS), mais cela rend également les API qui prennent en charge l'authentification et la récupération de données vulnérables aux attaques par force brute et par énumération, y compris le craquage de jetons et de justificatifs d'identité.

Selon le Rapport sur l'état de la sécurité des API T1 2023, seulement 54 % des répondants priorisent le Top 10 de la sécurité des API de l'OWASP dans le cadre de leurs programmes de sécurité, même si 62 % des tentatives d'attaques contre les organisations exploitent au moins une de ces méthodes.

Top 10 des menaces de sécurité des API OWASP.

En quoi la sécurité des API est-elle différente ?

Les solutions de sécurité traditionnelles, y compris les WAF, les passerelles API, les outils de gestion des API et les outils de gestion des identités et des accès (IAM), n'ont pas été conçues pour prévenir les attaques contre les API. C'est parce que la sécurisation des API présente des défis uniques :

Prolifération des API : un paysage en constante évolution

Avec les API constamment développées et modifiées par les équipes DevOps d'aujourd'hui, les types de menaces auxquelles les API sont confrontées ont également changé. Dans le passé, les attaques basées sur les transactions, telles que l'injection SQL et d'autres méthodes d'exécution de code, étaient les tactiques les plus répandues, mais les attaques actuelles visent souvent à exploiter la logique applicative et métier sous-jacente à chaque API. Avec 37 % des entreprises qui mettent à jour leurs API une fois par semaine, il n'est pas réaliste de s'attendre à ce que les équipes de développement détectent chaque vulnérabilité API possible avant de déployer une API nouvelle ou mise à jour.

Attaques d'API lentes et discrètes : le pouvoir de la reconnaissance

Les attaques traditionnelles, comme les injections SQL ou le cross-site scripting, se produisent toujours, mais les attaques d'API les plus réussies d'aujourd'hui, basées sur la logique applicative, ne suivent pas ces mécanismes « uniques et ponctuels » qui exploitent des vulnérabilités connues. Parce que chaque point d'accès API est différent et que chaque attaque découle rarement d'un seul appel API, chaque attaque API est essentiellement une attaque « zero-day », les outils traditionnels étant incapables de les détecter via leurs approches basées sur des règles et des signatures. Les acteurs malveillants prennent leur temps avec leurs activités de reconnaissance. Ils peuvent prendre des semaines, voire des mois, pour rechercher des données, sonder les failles et induire des comportements anormaux afin de trouver des moyens subtils de perturber la chaîne d'approvisionnement ou d'exfiltrer des données d'une API.

Les lacunes des tactiques de « shift-left » et la nécessité d'une protection au moment de l'exécution

Historiquement, les organisations se sont appuyées sur les tests pour détecter les failles de sécurité avant de déployer une application. Cependant, l'adoption généralisée des méthodologies de développement agile et le problème de la prolifération des API ont rendu le test de chaque vulnérabilité d'API tout simplement impossible. Bien que les tests standard de pré-production puissent identifier certaines lacunes dans les meilleures pratiques de sécurité des API, ils ne révéleront pas les vulnérabilités enracinées dans les lacunes de la logique métier des API — qui sont précisément les failles que les attaquants d'aujourd'hui chercheront à exploiter. De plus, il n'est pas réaliste de s'attendre à ce qu'un développeur écrive un code entièrement sécurisé à chaque fois, la seule façon de détecter et d'arrêter les menaces d'API est donc de mettre en place une protection au moment de l'exécution.

Quelles pratiques exemplaires de sécurité des API peuvent être utilisées pour prévenir et atténuer les attaques actuelles ?

Les API sont difficiles à protéger. Les solutions traditionnelles ne peuvent pas gérer les complexités de l'écosystème des API. Les attaquants le savent, c'est pourquoi ils se concentrent sur les API.

Les meilleures pratiques suivantes peuvent vous aider à améliorer la posture de sécurité de vos API :

Développement et tests

  • Promouvoir la sécurité Conception d'API et développement : Créez des pratiques de codage et de configuration sécurisées pour la construction et l'intégration des API. L'OWASP Application Security Verification Standard (ASVS) est une bonne ressource.
  • Réduisez l'exposition des données sensibles: Évitez d'envoyer trop de données aux applications clientes et de vous fier à elles pour filtrer les données.
  • Menez des revues de conception : Assurez-vous d'inclure la logique métier dans les revues de conception.
  • Documentez vos API : La documentation aide les gens à comprendre comment une API est construite ou intégrée. Vous avez particulièrement besoin de documentation pour les revues de conception, les tests de sécurité et la protection.
  • Utilisez un format lisible par machine pour la documentation : Utilisez des formats lisibles par machine tels que Spécification OpenAPI (OAS). Vous pouvez ensuite utiliser les spécifications pour les tests et la protection de base.
  • Maintenez un inventaire précis des API : Donnez à vos équipes de sécurité une vue réaliste de la surface d'attaque grâce à un inventaire à jour. La meilleure façon de capturer ces informations est avec des outils automatisés Découverte d'API qui couvre REST, GraphQL et d'autres formats d'API.
  • Effectuez des tests de sécurité : Utilisez des outils de test de sécurité pour identifier les problèmes de configuration ou les vulnérabilités dans vos API. Les scanners ne sont pas efficaces pour analyser la logique métier, vous devez donc analyser vos API et effectuer des tests de fuzzing en cours d'exécution pour identifier le code exploitable.

Production

  • Activez la journalisation et la surveillance : Les données de télémétrie vous aident à détecter les attaques, à répondre aux incidents et à protéger les API en cours d'exécution. Utilisez ces données comme référence pour un comportement normal. Ainsi, tout événement aberrant peut être rapidement identifié et résolu.
  • Médiatisez vos API : Utilisez des outils de médiation comme les passerelles API pour améliorer la visibilité et la sécurité. Étendez les capacités de ces plateformes avec une solution de sécurité API qui fournit un contexte plus approfondi sur les API.
  • Identifier la dérive des API : Assurez-vous d'avoir un plan pour déterminer quand une API a changé. Encore une fois, les plateformes automatisées capables de comparer la documentation au comportement d'exécution de vos API aideront à identifier ces lacunes. Mettez ensuite votre documentation à jour en conséquence.
  • Utilisez les bons contrôles de sécurité réseau : Certains contrôles réseau peuvent contribuer à la sécurité des API. Par exemple, chiffrez les données envoyées par les API. Vous pouvez également utiliser la limitation de débit dynamique et les listes d'adresses IP autorisées et refusées (en supposant que le nombre d'utilisateurs d'API est faible).
  • Authentifier et autoriser en continu : Externalisez les contrôles d'accès et les référentiels d'identité. Incluez les passerelles API, les référentiels d'identité, IAM, la gestion des clés, l'infrastructure à clé publique et la gestion des secrets à cette étape. Évitez d'utiliser des clés API pour l'authentification.
  • Déployez une protection d'exécution : Assurez-vous que votre protection d'exécution peut identifier les problèmes de configuration dans l'infrastructure API. Elle devrait également détecter les anomalies de comportement telles que bourrage d'identifiants, les tentatives de force brute ou de scraping.

Quelles méthodes et quels outils peuvent être utilisés pour protéger les API ?

La meilleure protection pour les API est une plateforme dédiée, conçue dès le départ en tenant compte de la sécurité des API. La bonne plateforme de sécurité des API devrait automatiquement :

  • Découvrez toutes les API nouvelles et modifiées, ainsi que toutes les données sensibles qu'elles exposent.
  • Détecter et arrêter les attaques sur les API pendant la phase de reconnaissance.
  • Éliminez les vulnérabilités en phase de construction chaque fois que possible, en fournissant des informations exploitables à vos équipes de développement.

Protection sur l'ensemble du cycle de vie des API

Sécurité des API sur l'ensemble du cycle de vie des API.

Une solution complète de sécurité des API devrait être capable de collecter, stocker et analyser des centaines d'attributs sur des millions d'utilisateurs et d'appels d'API et, plus important encore, d'exploiter l'intelligence artificielle (IA) et l'apprentissage automatique (ML) pour les corréler dans le temps. L'acquisition de cette ampleur de contexte nécessitera des mégadonnées à l'échelle du cloud, car les approches basées sur des serveurs ou des machines virtuelles n'auront pas un ensemble de données suffisamment large dans le temps pour identifier les attaques d'API sophistiquées, lentes et discrètes d'aujourd'hui. Ce n'est qu'avec ce type d'intelligence adaptative et de contexte approfondi que vous disposerez de ce dont vous avez besoin pour protéger toutes vos API.

Pour en savoir plus sur la façon dont Salt peut aider à défendre votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démo personnalisée.

Prêt à nous voir en action ?

Planifiez une démo aujourd'hui pour découvrir comment vous protéger du vecteur de menace des API.