Recherche sur les menaces API : failles d'autorisation GraphQL dans une plateforme de technologie financière

Résumé de l'incident

Les chercheurs de Salt Labs ont étudié une importante plateforme de technologie financière (FinTech) interentreprises (B2B) qui propose des services financiers sous forme d'applications mobiles basées sur des API et de logiciels en tant que service (SaaS) aux petites et moyennes entreprises (PME) et aux marques commerciales. En raison de vulnérabilités d'API identifiées par nos chercheurs, ces derniers ont pu lancer des attaques permettant de :

1. N'importe quel utilisateur pouvait soumettre des transactions non autorisées sur les comptes d'autres clients
2. N'importe quel utilisateur pouvait collecter des données sensibles sur les clients

L'organisation utilisait GraphQL dans sa pile technologique pour gérer les activités de compte des clients utilisant des applications mobiles. Elle exploitait également une API tierce pour récupérer l'historique des transactions des comptes clients. L'implémentation ne parvenait pas à authentifier et autoriser correctement les clients. Par conséquent, les chercheurs de Salt Labs ont pu soumettre des transactions non autorisées sur les comptes d'autres clients du fournisseur de services financiers, corréler l'activité des comptes utilisateurs et récupérer des informations personnelles identifiables (PII) sur les clients. Comme pour de nombreuses implémentations d'API défaillantes, un certain nombre de problèmes permettant d'exploiter les services correspondent au OWASP API Security Top 10, notamment :

• Autorisation au niveau de l'objet défaillante (BOLA)
• Authentification défaillante
• Exposition excessive de données

Les services en question proviennent d'une division FinTech d'une grande marque grand public qui propose à la fois des offres B2B et B2C. Il est essentiel de préserver l'anonymat de ce fournisseur de services ; nous avons donc nettoyé tous les détails techniques susceptibles d'identifier l'organisation. Après avoir identifié la vulnérabilité, nous avons examiné nos conclusions et fourni des recommandations d'atténuation à l'organisation. Dans le cadre de la mission plus large de Salt Labs, nous partageons ces conclusions ici afin de sensibiliser aux vulnérabilités des API, notamment en expliquant le modèle d'attaque, en détaillant les étapes de propagation de l'attaque et en soulignant les techniques d'atténuation.

Motivation de la recherche

Salt Labs mène des recherches sur les menaces pour aider ses clients et prospects à identifier les vulnérabilités de leurs propres API. Le laboratoire étudie également des plateformes publiques afin de découvrir des failles de logique applicative, en suivant des pratiques de divulgation responsable et en travaillant avec les organisations concernées pour résoudre les problèmes liés aux API. Nous publions ces informations — anonymisées si nécessaire — pour aider les praticiens à apprendre des erreurs des autres et à éviter tout incident ultérieur.

Dans ce cas précis, les chercheurs de Salt Labs ont étudié la plateforme de technologie financière en ligne car l'entreprise s'inquiétait de potentielles failles de sécurité au niveau de ses API et a sollicité l'aide de Salt Security. L'implémentation utilisait des services GraphQL, dont la popularité ne cesse de croître. Plusieurs aspects de la structure des API GraphQL peuvent créer des risques de sécurité plus difficiles à évaluer. La sensibilisation à la sécurité autour de GraphQL est encore relativement faible, et les détails de la vulnérabilité de l'implémentation API de cette organisation offrent une valeur pédagogique supplémentaire pour le secteur.

Les impacts commerciaux potentiels de la faille de sécurité API que nous avons découverte

Une vulnérabilité courante liée à GraphQL est que les développeurs doivent implémenter l'autorisation à chaque couche d'une requête GraphQL multicouche pour prévenir les attaques. Cet effet secondaire alourdit la charge de travail des équipes de développement et d'exploitation, et peut prolonger les délais de livraison pour les applications comportant de nombreux points de terminaison API. Cela peut également créer une situation plus vulnérable à l'erreur humaine. Certains points de terminaison peuvent être oubliés ou ne pas être traités correctement, ce qui entraîne son propre lot de problèmes par la suite. À l'inverse, les API REST incluent des contrôles d'authentification et d'autorisation inhérents, à condition que des mécanismes tels qu'OpenID Connect (OIDC) et OAuth2 soient correctement implémentés.

En moyenne, les applications mobiles présentent un nombre de vulnérabilités nettement plus élevé que les applications web. L'authentification et l'autorisation sont souvent faibles, défaillantes ou absentes dans la conception des applications mobiles, les développeurs se concentrant principalement sur la mobilité et l'ergonomie. Les canaux mobiles sont également souvent moins sécurisés que les canaux web. Par ailleurs, les bases de code peuvent être gérées par des équipes distinctes, ce qui entraîne des divergences dans la posture de sécurité des API. Les attaquants connaissent cette réalité et alternent entre les clients front-end et les services back-end pour trouver le maillon faible lorsqu'ils ciblent des fonctionnalités ou des données. Les communications par API web sont souvent chiffrées avec SSL ou TLS, ce qui donne aux organisations un faux sentiment de sécurité quant à la résistance d'une application ou d'une API face aux attaques. Dans ce cas, les chercheurs de Salt Labs ont pu isoler les appels API, demander des données via un navigateur web standard et recevoir des identifiants sensibles qui ont permis des attaques contre le mécanisme d'autorisation utilisé par l'application.

Attaque : Soumettre des transactions de compte non autorisées au nom de clients

Les organisations doivent gérer plusieurs types de front-ends applicatifs, généralement des applications web et mobiles, qui interagissent à leur tour avec de nombreux services back-end. Les flux applicatifs invoquent généralement un certain nombre d'appels API internes et externes pour fournir des fonctionnalités ou des données, et ces flux peuvent varier selon le type d'utilisateur ou l'application cliente associée. S'assurer qu'une entité authentifiée est autorisée à accéder à une ressource donnée tout au long d'une session est plus facile à dire qu'à faire, d'autant plus que la plupart des organisations travaillent également avec d'autres partenaires pour activer des fonctionnalités dans le cadre d'une chaîne d'approvisionnement numérique plus large. Une fois qu'un attaquant a obtenu une session authentifiée, même avec des niveaux de permission de base, il peut abuser de l'autorisation pour accéder à d'autres données ou fonctionnalités fournies par les API et intégrées à la conception globale de l'application.

Dans le cadre de nos recherches, nous avons pu modifier les numéros de compte des appels API et effectuer des virements de fonds non autorisés. Les numéros de compte sont une forme de données personnelles (PII), mais ils sont également utiles pour perpétrer des fraudes, car un attaquant peut utiliser ces informations pour effectuer des actions sur d'autres comptes si une API n'applique pas correctement l'autorisation. Dans cet incident, l'un des numéros de compte était un identifiant unique délivré par le gouvernement, et l'autre était un identifiant de compte financier. Les numéros de compte pouvaient être collectés et corrélés via un point de terminaison d'API tiers, ce qui est abordé dans la section suivante de ce rapport sur les menaces.  

Attaque : Désanonymiser et corréler l'activité des comptes

Les organisations externalisent régulièrement leurs activités, notamment l'ingénierie système et les opérations. Cette pratique commerciale est particulièrement courante pour les applications et les API, car le travail de développement et les artefacts de code peuvent être confiés partiellement ou totalement à des tiers. Malheureusement, l'un des sous-produits de l'externalisation est souvent un manque de connaissance de l'architecture complète et des flux applicatifs de bout en bout. Les bizarreries dans l'expérience utilisateur sont souvent le meilleur des scénarios. Dans le pire des cas, des failles de sécurité importantes apparaissent lorsque l'infrastructure est mal configurée ou que le code présente des faiblesses. Ces erreurs peuvent entraîner l'exposition de données sensibles, une logique métier abusive et des vulnérabilités exploitables pour les organisations.

Dans nos recherches, nous avons découvert une API tierce intégrée qui exposait par inadvertance des données sensibles permettant de désanonymiser les clients et de permettre aux attaquants de corréler l'activité des comptes. Des données personnelles, notamment les noms, adresses et numéros de compte, ont été exposées par ce point de terminaison d'API tiers. La seule donnée requise pour appeler cette API et obtenir les données personnelles était un identifiant d'enregistrement d'une transaction antérieure. Les données sensibles telles que celles découvertes ici sont soumises à de nombreuses formes de réglementations nationales et régionales qui régissent l'activité commerciale et la confidentialité des utilisateurs. Une telle exposition de données peut entraîner des sanctions réglementaires et des amendes.

Les détails techniques de cette faille de sécurité API

Nos chercheurs ont analysé l'application mobile et les API back-end grâce à une combinaison de méthodes incluant :

• Analyse du dépôt Postman
• Rétro-ingénierie de l'application mobile

En utilisant un dépôt Postman fourni par le client, nos chercheurs ont examiné la structure de l'API utilisée par les clients des applications mobiles. Les chercheurs ont commencé à comprendre quels types de requêtes permettraient d'obtenir des données utiles pouvant être exploitées. En parallèle, nos chercheurs ont également effectué une rétro-ingénierie de l'application mobile et ont corrélé leurs conclusions concernant les appels API avec les enregistrements du dépôt Postman. Nos chercheurs ont trouvé et modifié le certificat SSL/TLS intégré à l'application mobile, utilisé pour l'épinglage de certificat et le chiffrement des communications API. Ce contournement d'un contrôle côté client a permis à nos chercheurs d'inspecter et de manipuler le trafic API provenant de l'application mobile.

Via l'application mobile, un attaquant pouvait voir le destinataire d'un transfert d'argent. L'exercice de l'API via Postman a également exposé des données personnelles liées à l'expéditeur et au destinataire. De plus, les appels API incluaient des données précieuses que nos chercheurs pouvaient utiliser pour corréler l'activité des clients et manipuler les appels API afin de pouvoir agir sur un compte. Nos chercheurs ont validé ce modèle d'attaque en choisissant un utilisateur, en tentant un virement de fonds sur le compte et en visualisant la transaction dans l'application mobile.

Les chercheurs ont également découvert des appels vers un point de terminaison d'API tiers non authentifié qui répondait avec un PDF du reçu d'une transaction donnée lorsqu'il était fourni avec un identifiant de transaction unique. Le point de terminaison de l'API tierce renvoyait également d'autres données personnelles, notamment des noms, des adresses, des montants en dollars et des identifiants de compte, utiles pour vérifier si les tentatives de transaction malveillantes avaient réussi.

Ces vulnérabilités de sécurité étaient situées sur un point de terminaison d'API GraphQL, un type d'API qui a gagné en popularité par rapport aux API REST pour la conception d'applications mobiles. L'organisation n'authentifiait ni n'autorisait les requêtes en vérifiant l'identité de l'expéditeur lors des demandes de virement de fonds. Des techniques d'attaque similaires fonctionnent pour les conceptions d'API GraphQL et REST. La complexité de GraphQL, telle que les requêtes imbriquées, exacerbe souvent les défis liés à l'autorisation, car un seul appel API peut consolider plusieurs requêtes et points de terminaison d'API.

N'importe quel utilisateur pouvait soumettre des transactions non autorisées contre d'autres clients

L'OWASP définit les problèmes d'autorisation comme une autorisation au niveau de l'objet défaillante (BOLA)Les attaquants exploitent les failles BOLA pour élever leurs privilèges et accéder à des données pour lesquelles ils ne sont pas autorisés. Dans ce cas, les chercheurs de Salt Labs ont pu manipuler des requêtes GraphQL afin de modifier les cibles de virements de fonds et d'autoriser automatiquement ces mêmes transactions.  

Les chercheurs de Salt ont découvert qu'un point de terminaison d'API GraphQL autorisait des paramètres de requête contrôlés par le client dans le corps du message de la requête API. Le point de terminaison de l'API se présentait comme suit :

“/BFF/graphql/mutation/doPayment”

Dans cette attaque BOLA, la séquence d'appel API se composait des étapes suivantes :

1. Un attaquant appelle le point de terminaison en utilisant l'identifiant unique (UID) de la victime pour déposer des fonds d'un compte bancaire vers un portefeuille numérique. Il n'y a aucune limite sur le montant pouvant être transféré, mais dans ce cas, un virement de 100 $ a été tenté à titre de test.

2. Le serveur répond avec un message d'état 200 OK confirmant que la transaction a été soumise avec succès. Dans la charge utile, la variable « status » indique également que la transaction est en attente de confirmation. La conception de l'application ne prévoit aucune notification à la victime concernant ce transfert. Le propriétaire du compte d'origine ne saurait pas que de l'argent a été transféré depuis son compte, à moins de surveiller étroitement l'activité de celui-ci. La valeur TID est l'identifiant de transaction qui peut être utilisé pour consulter l'enregistrement de la transaction sur un point de terminaison d'API tiers distinct.

La valeur UID ici est un identifiant national unique. Si cette valeur est inconnue de l'attaquant, il peut obtenir l'information en appelant un point de terminaison d'API tiers distinct, comme décrit dans la section suivante. Lors de l'interrogation de cette API tierce avec un identifiant de transaction, un reçu de la transaction donnée est présenté à l'attaquant au format HTML ou PDF. Ce reçu de transaction inclut le numéro de compte de la victime, l'identifiant du portefeuille numérique, l'adresse, le montant d'argent et d'autres exemples de données PII. Grâce à ces données PII obtenues, l'attaquant peut initier des virements vers n'importe quel autre compte ou utilisateur.

N'importe quel utilisateur pourrait collecter des données sensibles sur les clients

Au cours de la recherche sur les menaces, les chercheurs de Salt Labs ont également découvert un point de terminaison d'API tiers qui ne nécessitait aucune authentification et exposait également des données sensibles. Le premier de ces problèmes correspond à OWASP API2 : Authentification utilisateur défaillante. Le second problème correspond à OWASP API3 : Exposition excessive de données.  

Les chercheurs de Salt ont découvert une fonction au sein du point de terminaison de l'API GraphQL qui, à son tour, appelait le point de terminaison de l'API tiers vulnérable. Le point de terminaison de l'API GraphQL se présentait comme suit :

“/BFF/graphql/mutation/receiptUrl”

Dans cette attaque de collecte de données, la séquence d'appel API se composait des étapes suivantes :

1. Après qu'un utilisateur a soumis une transaction réussie dans l'application mobile, laquelle appelle à son tour le point de terminaison GraphQL pour la fonction doPayment, l'application mobile effectue ensuite un autre appel au point de terminaison GraphQL pour fournir un enregistrement de la transaction. La requête contient l'identifiant utilisateur, UID, et l'identifiant de transaction, TID. Cette requête ressemblait à ce qui suit :

2. La réponse à cet appel d'API GraphQL contient un appel d'API REST imbriqué qui est à son tour invoqué par l'application mobile pour renvoyer un enregistrement de la transaction au format PDF. Cette réponse ressemble à ce qui suit :

3. Cette URL imbriquée peut être appelée directement avec une requête HTTP GET de base ou simplement en lançant l'URL dans un navigateur. Seul l'identifiant de transaction, TID, était nécessaire comme paramètre, et aucune session authentifiée n'était requise pour récupérer les données. L'API tierce répond avec un enregistrement complet de la transaction au format PDF. Ce reçu PDF inclut le compte de la victime, l'identifiant du portefeuille numérique, le nom, l'adresse, les montants en dollars et d'autres exemples de données PII.

Le point de terminaison de l'API tiers a été utile pour valider que l'attaque BOLA fonctionnait comme prévu. L'API tierce exposait également trop de données sensibles, et effectuer les appels en dehors de l'application mobile sans aucun contexte authentifié a permis de confirmer que les contrôles d'accès n'étaient pas appliqués. Ces données sont utiles pour perpétuer d'autres types de fraude sur la plateforme, et peuvent également être utilisées pour désanonymiser les clients et corréler l'activité des comptes. Le point de terminaison de l'API semblait également manquer de contrôles de ressources ou de limitation de débit, ce qui aurait rendu possible une énumération plus poussée des identifiants de transaction et un scraping massif.

Méthodes pour combler cette faille de sécurité API

L'exploitation des failles de cette plateforme de services financiers en ligne interentreprises (B2B) nécessiterait la corrélation des données fournies par des API tierces et une manipulation spécifique de la logique métier utilisée par l'API GraphQL des interfaces mobiles. Les techniques de remédiation et d'atténuation appropriées doivent également être spécifiques.

Atténuer les failles d'autorisation permettant à un attaquant de soumettre et d'autoriser automatiquement des transactions

Une API sécurisée doit exiger une vérification systématique que l'utilisateur demandant des données ou une fonctionnalité est bien autorisé à y accéder. Le système doit valider en continu l'autorisation pour chaque session et à chaque demande d'accès aux données. Cette approche d'autorisation continue est fondamentale pour le principe du moindre privilège, qui est lui-même une prémisse essentielle de l'architecture « zero-trust ».

Les organisations doivent appliquer les contre-mesures suivantes pour atténuer les faiblesses d'autorisation identifiées par Salt Labs :

1. Autoriser en continu - l'API et les services back-end intégrés doivent utiliser une validation continue pour garantir que l'utilisateur authentifié est autorisé à accéder aux données ou à la fonction demandée.
2. Renvoyer des codes d'erreur HTTP précis - Si un utilisateur authentifié tente d'accéder aux enregistrements d'un autre utilisateur, le serveur doit répondre avec un code d'état HTTP « 401 Unauthorized » ou « 403 Forbidden », et/ou rediriger l'utilisateur non authentifié vers une page de connexion affichant un code d'état HTTP 30X.
3. Invalider les sessions de requêtes abusives - Concevoir la plateforme de manière à surveiller et invalider les sessions où les utilisateurs effectuent des requêtes excessives, énumèrent des enregistrements ou tentent à plusieurs reprises d'accéder à des données non autorisées.
4. Éviter les noms par défaut ou simples - Utiliser des noms et des index uniques que les attaquants ne peuvent pas facilement deviner, forcer ou énumérer.
5. Utiliser des limites de débit - Appliquer des limites de débit sur les points de terminaison de l'API pour empêcher l'énumération, tout en tenant compte du fait que les attaquants ralentiront leurs taux de requête pour échapper à la détection.
6. Assurer la cohérence de l'authentification et de l'autorisation entre les canaux web et mobiles - Les plateformes doivent être conçues pour mettre en œuvre l'autorisation et l'authentification sur ces points de terminaison vulnérables et lorsque les utilisateurs basculent entre les canaux ou les interfaces. Le SSL et le TLS aident à chiffrer les communications API, mais une telle protection de transport peut être contournée par les attaquants.

Atténuer le risque de désanonymisation et de corrélation

De nombreuses implémentations d'API sont des écosystèmes étendus ou des chaînes d'approvisionnement numériques, où une organisation s'intègre à un nombre quelconque d'API et de services tiers pour faciliter ses activités. C'était le cas pour cette organisation financière, car l'un des points de terminaison d'API tiers renvoyait des identifiants de compte qui sont devenus utiles pour perpétuer l'attaque par autorisation. Ce point de terminaison d'API tiers ne nécessitait également aucune authentification, et encore moins d'autorisation.

Appliquer les contre-mesures suivantes pour atténuer les faiblesses de désanonymisation et de corrélation identifiées par Salt Labs :

1. Authentifiez systématiquement et autorisez en continu — Toute API traitant des données sensibles doit exiger une authentification et vérifier en permanence si l'utilisateur authentifié est autorisé à accéder à la ressource demandée.
2. Utilisez des limites de débit — Appliquez des limites de débit sur les points de terminaison de l'API pour empêcher les formes élémentaires d'énumération et atténuer le risque de scraping massif. Gardez à l'esprit que les attaquants ralentiront également leurs taux de requête pour échapper à la détection ou déclencher une limite de débit.
3. Utilisez une entropie suffisante — Assurez-vous que tous les identifiants sont suffisamment longs, complexes et aléatoires pour limiter l'efficacité des techniques d'énumération et d'attaques par force brute. Cette mesure peut également contribuer à maintenir la pseudonymisation en rendant plus difficile pour les attaquants la corrélation entre les comptes et les données.
4. Évitez d'utiliser des identifiants statiques comme facteur d'authentification — Les identifiants d'enregistrement doivent être suffisamment complexes et aléatoires. De plus, si de tels identifiants sont utilisés comme facteur d'authentification, ils doivent être dynamiques et temporaires. Avec suffisamment de temps et en fonction des mesures de limitation de débit, les attaquants peuvent forcer ces valeurs utilisées dans les appels API. Ce type de faille API est similaire à la dépendance aux clés API comme seul moyen d'authentification pour les appelants. Ces données peuvent être et seront récoltées ou forcées par des attaquants.
5. Évitez d'exposer trop de données dans les réponses — N'envoyez pas aux clients des données qui ne sont pas nécessaires à l'exécution d'une fonction donnée. Tenez également compte de toute réglementation ayant un impact sur la transmission et la conservation des données sensibles, en particulier en ce qui concerne la confidentialité.
6. Validez la sécurité des services tiers dans la mesure du possible — Les partenaires et fournisseurs doivent également fournir un niveau de garantie concernant la sécurité des API, la sécurité des données et la confidentialité des utilisateurs. Certains éléments de sécurité tiers peuvent être validés par l'organisation principale, comme la vérification que les points de terminaison de l'API exigent TLS et une authentification. Vous devrez peut-être également demander des attestations aux fournisseurs, car tout le code ou la configuration ne sera pas visible par l'organisation principale.

Leçons apprises

Les trois principaux problèmes du Top 10 de l'OWASP sur la sécurité des API étaient tous présents dans cette architecture d'application : autorisation défaillante, authentification défaillante et exposition excessive de données. L'organisation utilisait une technologie plus récente sous la forme de GraphQL, ce qui apporte une complexité accrue et un risque plus élevé de problèmes d'autorisation. GraphQL gagne en adoption en tant qu'activateur du modèle de conception « back end for front ends » (BFF). De nombreuses organisations poursuivent activement des initiatives GraphQL là où elles doivent fournir un certain nombre de services à de larges bases d'utilisateurs, pour lesquelles même la moindre latence potentielle pour les systèmes front-end comme les applications mobiles est préoccupante. Les praticiens doivent toutefois être conscients que les implémentations GraphQL sont sensibles à bon nombre des mêmes modèles d'attaque API que REST. Les risques de sécurité potentiels peuvent également être aggravés par GraphQL, en particulier avec les attaques DoS au niveau de l'application et les failles d'autorisation.

Les attaquants utilisent des techniques qui fonctionnent universellement pour les API GraphQL et REST. L'une des plus grandes fonctionnalités de GraphQL, la capacité de consolider les requêtes et les points de terminaison, augmente également le risque de sécurité. La mise en œuvre d'une autorisation adéquate devient une entreprise complexe lorsque l'on prend en compte toutes les manières dont un front-end donné peut solliciter une API GraphQL, qui appelle à son tour d'autres API back-end. GraphQL présente d'autres risques de sécurité potentiels dont les organisations doivent être conscientes lorsqu'elles adoptent cette technologie plus récente. La « sécurité par l'obscurité » n'est jamais une stratégie solide. Les organisations doivent opérer avec l'état d'esprit que les attaquants feront régulièrement de l'ingénierie inverse sur les applications et les appels API, ce qui inclut toutes les formes de binaires d'applications mobiles et de protocoles API.

Un thème récurrent dans la sécurité des API est que l'architecture compte. Ce principe est vrai pour vos propres conceptions d'API, ce que vous recherchez dans les solutions et la manière dont vous abordez la stratégie de sécurité. Les organisations consacrent souvent beaucoup de main-d'œuvre à des tests approfondis, parfois automatiquement dans le cadre de pipelines de construction, mais toujours avec l'objectif d'essayer d'identifier autant de problèmes au niveau du code et de mauvaises configurations que possible avant la mise en production. Malheureusement, tester tous les flux d'applications et les séquences d'appels API est plus facile à dire qu'à faire avec les outils de test de sécurité traditionnels. De plus, l'analyse du code avant sa mise en production a ses limites — en effet, la plupart des cas de logique métier exploitable ne peuvent être trouvés qu'en analysant les comportements lors de l'exécution. Le problème ne fait qu'empirer avec l'externalisation du développement et des opérations. Une application entièrement intégrée et tous ses services forment une toile d'araignée complexe de services internes et externes ainsi que de connexions de partenaires qui peut être décrite comme une chaîne d'approvisionnement numérique.

Salt Labs a détaillé les vulnérabilités de GraphQL, les étapes qu'un attaquant pourrait suivre et les actions préventives que les organisations peuvent prendre pour atténuer ces types d'attaques. Il est essentiel que toute API traitant des données sensibles, quel que soit le protocole, exige une authentification et une autorisation. Le contrôle d'accès et la surveillance de l'activité doivent être continus tout au long de toutes les sessions pour garantir que les appelants de l'API ne demandent pas de données ou de fonctionnalités pour lesquelles ils ne sont pas autorisés. Une telle approche est fondamentale pour la sécurité des API ainsi que pour d'autres principes de sécurité, notamment le moindre privilège et l'architecture zéro confiance.

Salt Labs publie des recherches sur les menaces liées aux API et des recommandations d'atténuation pour aider à sensibiliser au domaine de la sécurité des API et à éduquer les praticiens. Toutes les organisations construisent ou intègrent des API à un titre ou à un autre. Beaucoup travaillent également avec des partenaires et des fournisseurs pour alimenter leur activité et fournir des services aux clients. Toutes les organisations peuvent bénéficier d'une approche du cycle de vie complet de la sécurité des API, et beaucoup devraient rechercher des outils de sécurité API dédiés afin de pouvoir trouver et traiter l'ensemble des problèmes potentiels de sécurité des API.

Si vous souhaitez voir la plateforme de protection des API de Salt Security en action, contactez-nous pour une démonstration personnalisée dès aujourd'hui !

‍