Pourquoi les tests de sécurité des API passent à côté des chaînes d'attaque inter-actifs

Votre scanner d'API peut vous remettre un rapport sans aucune alerte pendant qu'un attaquant entre comme chez lui. Sa requête est valide, elle porte un vrai jeton, et le serveur y répond correctement. Le problème, c'est l'origine du jeton. Il vient d'un endroit que votre scanner n'a jamais vérifié : une chaîne compilée dans votre application mobile, une route oubliée dans un bundle JavaScript ou un secret resté dans l'historique Git.

Les tests de sécurité des API seuls échouent parce que de nombreuses compromissions d'API à fort impact ne commencent pas au niveau de l'API. Elles commencent par un identifiant, une route ou un format de requête extraits d'une application mobile, d'un bundle JavaScript ou du code source, puis rejoués sous la forme d'une requête valide. Un scanner qui ne teste que l'API ne voit jamais où la chaîne commence.

Dans une application iOS que nous avons évaluée, un secret Auth0 codé en dur a mené à un annuaire de 1 000 enregistrements d'utilisateurs, alors que le premier résultat portant sur cet identifiant avait déjà été marqué Fixed & Verified. Cette histoire est racontée plus bas. Ce guide s'adresse aux responsables AppSec et aux ingénieurs DevSecOps dont les API servent des clients mobiles ou web.

Résumé (TL;DR)

• Dans nos évaluations, beaucoup des résultats les plus graves sur les API ne commençaient pas à l'API. Ils commençaient par un identifiant ou une route extraits d'une application cliente ou du code, puis rejoués comme une requête valide.
• Les scanners qui testent un seul actif à la fois voient chacun la moitié de cette chaîne. Rassembler leurs rapports dans un même tableau de bord après coup ne relie pas les deux moitiés.
• Pour détecter ces chaînes, testez les applications clientes, le code et l'API active dans une même évaluation, et appliquez les correctifs côté serveur.

Qu'est-ce qu'une chaîne d'attaque inter-actifs ? Une chaîne d'attaque inter-actifs est une série de faiblesses réparties sur plusieurs actifs, par exemple une application mobile, un frontend web, un dépôt de code source et une API backend. Chaque faiblesse paraît mineure isolément. Ensemble, elles donnent à un attaquant accès à des données ou à des fonctions qu'il ne devrait jamais atteindre.

La chaîne typique comporte trois étapes :

1. Extraire quelque chose d'un client ou du code : un jeton, une clé de signature, une route non documentée ou un format de requête.
2. Rejouer cet élément contre une API backend sous la forme d'une requête valide.
3. Escalader grâce à une faille d'autorisation côté serveur : l'objet d'un autre utilisateur (BOLA), une fonction privilégiée (BFLA) ou un périmètre de jeton plus large.

Aucune de ces étapes ne ressemble à une attaque prise isolément. La première est une chaîne statique, la deuxième est une requête authentifiée, la troisième est une réponse d'API ordinaire. La compromission n'apparaît que lorsqu'on les lit dans l'ordre.

À quoi ressemblent les chaînes d'attaque inter-actifs en pratique ?

Les deux chaînes ci-dessous proviennent d'évaluations réelles d'Ostorlab, chacune publiée plus en détail sur ce blog. Toutes deux ont fait intervenir Ostorlab Agentic Deep Scan, qui exécute des agents de test autonomes contre un actif : un binaire mobile dans le premier cas, du code source dans le second. Chacune est devenue une compromission confirmée seulement lorsque l'identifiant ou la route extraits ont été rejoués contre le backend actif.

1. D'un secret client Auth0 codé en dur dans une application iOS à des scopes d'administration sur tout le tenant

Dans une évaluation présentée dans How AI Catches Complex Vulnerabilities, une application iOS embarquait un client_id et un client_secret Auth0 de type machine-to-machine (M2M). Les deux étaient intégrés au moment du build via les DART_DEFINES de Flutter. L'application les utilisait pour appeler un service interne.

Le premier résultat portant sur cet identifiant, limité à l'unique audience que l'application appelle, avait été classé High et était déjà marqué Fixed & Verified. Le correctif fermait le chemin utilisé par l'application, pas tout ce que l'identifiant pouvait atteindre.

Un scanner statique signalerait la chaîne. Étant donné l'audience que l'application demande légitimement, un scanner d'API verrait un jeton correctement limité. Mais l'agent a posé une autre question. Un client M2M peut se voir accorder l'accès à plus d'une API : à quoi d'autre ce client était-il autorisé à accéder ?

Il a essayé 38 audiences candidates sur l'endpoint /oauth/token du tenant. L'Auth0 Management API (https://<tenant>.auth0.com/api/v2/) a répondu avec un HTTP 200 et un jeton portant huit scopes d'administration, dont update:users, delete:users et create:client_credentials. Un simple GET en lecture seule a ensuite exposé l'annuaire complet du tenant, soit 1 000 enregistrements, données personnelles (PII) comprises. Aucune écriture n'a été effectuée, mais le jeton aurait pu créer, modifier et supprimer des utilisateurs. Ce second résultat a été classé Critical et était toujours Open.

Figure 1 : un identifiant M2M extrait d'un binaire iOS se transforme en scopes d'administration sur l'Auth0 Management API.

Pourquoi un test à une seule couche passe à côté : l'identifiant se trouve dans le binaire, et l'autorisation trop large se trouve dans la configuration du fournisseur d'identité. Ni l'un ni l'autre n'apparaît dans la spécification de l'API.

2. L'endpoint de création qui transférait la propriété (BOLA)

Dans l'évaluation du code source de GoPhish, où une revue manuelle était associée à Ostorlab Agentic Deep Scan, l'endpoint de création de groupe (POST /api/groups/) effectuait un upsert silencieux. Un corps JSON valide portant l'id du groupe d'un autre utilisateur écrasait les données de destinataires de ce groupe et transférait la propriété à l'attaquant.

Agentic Deep Scan a repéré le motif dans le code, où les handlers de création acceptaient un id. L'évaluation l'a ensuite confirmé en rejouant la requête en tant que second utilisateur contre une instance GoPhish locale isolée, avec des comptes synthétiques. Ce rejeu écrase des données : il a sa place dans un laboratoire, pas en production.

Figure 2 : preuve anonymisée issue de l'évaluation de GoPhish. Un second utilisateur prend le contrôle d'un groupe existant grâce à une requête de création portant son ID. Les noms de comptes, les clés d'API et les endpoints sont synthétiques.

Pourquoi un test à une seule couche peut passer à côté : la requête était bien formée et authentifiée, et la faille se trouve dans la logique de propriété, pas dans la validation des entrées. Les vérifications de contrat et le fuzzing basé sur le schéma n'ont donc rien à signaler. Un test multi-utilisateurs ne la détecte que s'il envoie l'ID d'un autre utilisateur dans une requête de création. Lire le handler montre exactement où essayer cela.

Pourquoi les scanners d'API à une seule couche ratent-ils ces chaînes ?

Les scanners à une seule couche ratent ces chaînes parce que chacun ne voit que son propre actif : aucun ne relie un secret trouvé dans un client à l'API que ce secret déverrouille. La plupart des outils de sécurité couvrent un seul coin de la pile : le code source, le trafic de la passerelle ou du WAF, ou des requêtes de test contre un serveur de préproduction. Aucun n'est défaillant ; chacun teste son propre actif de façon isolée.

Mais les API backend sont appelées par des binaires mobiles (.ipa sur iOS, .apk sur Android), des applications web monopages, des intégrations partenaires et des services internes, et tous embarquent de la configuration, et souvent des secrets, à des endroits qu'un attaquant peut lire. Testés un par un, chaque actif peut réussir le test pendant que la chaîne qui les relie passe inaperçue. Certaines plateformes combinent désormais le test du code, de l'exécution et des API, ce dont ces chaînes ont besoin.

D'où fuitent les identifiants et les routes d'API ?

Les identifiants et les routes d'API fuient généralement de cinq sources qu'un attaquant peut exploiter : les binaires mobiles, les bundles web, les dépôts de code source et le CI, la documentation des API, et des canaux secondaires comme les WebSockets. Ce sont celles que nous rencontrons le plus souvent lors des évaluations :

Source	Ce qu'un attaquant extrait	Impact typique sur l'API
Binaires mobiles (APK / IPA / AAB)	Des identifiants confidentiels qui ne devraient jamais être livrés dans une application, comme les secrets client M2M et les valeurs client_secret partagées (le client_id public d'une application native est censé être visible), des clés d'API privilégiées injectées au moment du build (par exemple DART_DEFINES de Flutter ou BuildConfig d'Android), des clés de chiffrement et la logique de signature des requêtes, des endpoints cachés ou de débogage	Génération de jetons, contournement de la signature des requêtes, appels vers des API internes ou de préproduction
Bundles web (JavaScript de SPA, source maps)	Des routes d'administration et internes que l'interface n'affiche jamais, des endpoints derrière des feature flags, des clés d'API tierces, des noms d'opérations GraphQL	Endpoints non documentés (API fantômes), fonctions privilégiées accessibles sans contrôle côté interface (BFLA)
Dépôts de code source et CI	Des secrets dans l'historique des commits, des jetons de déploiement, des définitions de routes, des handlers sans middleware d'autorisation	Accès authentifié direct, et liste précise des routes sans contrôle de propriété
Documentation et collections d'API (OpenAPI, Postman, introspection GraphQL)	Les formes complètes des requêtes, des versions dépréciées toujours actives, les formats d'identifiants d'objets	Énumération massive et accès via d'anciennes versions de l'API (gestion d'inventaire inadaptée)
Canaux secondaires (WebSockets, gRPC-web)	Les chemins d'endpoints et les noms d'opérations exposés par le canal, et des handshakes qui contournent le middleware d'authentification HTTP	Flux de données ou abonnements non authentifiés (authentification défaillante, BFLA)

Un scanner qui travaille uniquement à partir d'un fichier OpenAPI et d'un compte de test démarre sans aucun de ces artefacts. Il teste donc l'API qu'utilise un client bien élevé. Il ne teste pas celle qu'utilisera un attaquant.

Quels risques de l'OWASP API Top 10 sont plus faciles à trouver avec un contexte extérieur à l'API ?

Les risques de l'OWASP API Security Top 10 (2023) sont des failles côté serveur : BOLA et BFLA se corrigent toujours dans l'API. Mais plusieurs d'entre eux sont plus faciles à découvrir ou à valider avec un contexte extérieur à l'API, comme une application cliente ou le code source :

Risque OWASP API	Contexte externe qui aide à le trouver ou à le valider	Ce que voit un scan limité à l'API
API1 : Broken Object Level Authorization (BOLA)	Les formats d'identifiants d'objets et le chiffrement des requêtes appris à partir de l'application cliente	Des requêtes sur ses propres objets de test, qui réussissent comme prévu
API2 : Broken Authentication	Des identifiants clients ou des jetons de longue durée extraits d'un binaire ou d'un dépôt	Rien, à moins que quelqu'un ne lui remette l'identifiant divulgué
API3 : Broken Object Property Level Authorization	Des champs cachés trouvés dans les modèles clients ou les types GraphQL	Uniquement les champs documentés dans la spécification
API5 : Broken Function Level Authorization (BFLA)	Des routes d'administration dans les bundles web, et des canaux secondaires comme les WebSockets	Les routes HTTP listées dans la spécification, et uniquement les rôles accordés à son compte de test
API8 : Security Misconfiguration	Des clients OAuth, des audiences ou des rôles cloud trop permissifs liés à un identifiant livré	Des problèmes de transport et d'en-têtes sur les endpoints qu'il connaît
API9 : Improper Inventory Management	Des hôtes de préproduction, d'anciennes versions et des endpoints de débogage référencés dans les clients et le code	Uniquement l'inventaire qu'on lui a fourni

Les quatre autres (API4 Unrestricted Resource Consumption, API6 Unrestricted Access to Sensitive Business Flows, API7 SSRF et API10 Unsafe Consumption of APIs) sont généralement testés depuis l'API.

Pourquoi les passerelles d'API, les plateformes ASPM ou les pipelines de scanners ne détectent-ils pas ces chaînes ?

La plupart des équipes disposent déjà d'une passerelle d'API, d'une plateforme ASPM ou d'un pipeline CI qui exécute plusieurs scanners. Chacun apporte quelque chose, mais aucun ne teste à lui seul un identifiant divulgué contre l'API. Prenons une chaîne courante : une application mobile embarque un jeton d'API codé en dur, un attaquant appelle le backend avec ce jeton, et une mauvaise configuration donne à ce jeton des droits d'administration.

La passerelle d'API laisse passer la requête

Une passerelle vérifie que les requêtes sont bien formées, applique des limites de débit et vérifie que les jetons sont authentiques et correctement signés. Dans cette attaque, la requête est valide et le jeton est réel. La passerelle n'a aucun moyen de savoir qu'un jeton livré dans une application publique ne devrait jamais porter de droits d'administration.

L'agrégation ASPM ne relie pas les points

Les plateformes de gestion de la posture de sécurité applicative (ASPM, Application Security Posture Management) rassemblent dans une seule vue les résultats des scanners mobiles, de code et d'API. Cela aide au tri et à l'attribution des responsabilités. Mais lorsque la corrélation intervient après la fin des scans, rien n'est testé d'un actif à l'autre. Certaines plateformes intègrent leurs propres scanners : la distinction qui compte est donc le moment de la corrélation, pas la catégorie de produit :

Dimension	Agrégation ASPM	Corrélation pendant le scan
Quand la corrélation a lieu	Une fois que chaque scanner a terminé	Pendant le scan, tant que les tests sont en cours
Ce qui est corrélé	Des résultats qui existent déjà	Des découvertes brutes : jetons, routes, formats de requêtes
Peut-elle tester un jeton divulgué contre l'API ?	Pas par l'agrégation seule ; elle relie deux résultats	Oui, le jeton devient l'entrée du test suivant en conditions réelles
Sortie	Deux résultats liés, souvent de sévérités différentes	Une chaîne validée avec preuve des requêtes et des réponses
Sévérité	Héritée de chaque scanner	Fondée sur l'impact démontré de la chaîne

Un pipeline de scanners exécute les outils à la suite, pas ensemble

Enchaîner des scanners dans le CI les exécute l'un après l'autre, mais aucun ne voit ce que les autres ont trouvé. Le scanner mobile trouve un secret client dans l'APK ou l'IPA, ne peut pas dire où il fonctionne et enregistre un résultat statique de faible sévérité. Le scanner d'API teste le backend à partir du schéma public et n'entend jamais parler du secret.

Comment un scan multi-actifs teste-t-il toute la chaîne ?

La corrélation pendant le scan signifie qu'une découverte dans un actif, comme une route dans le code source ou un jeton dans un binaire client, devient immédiatement l'entrée de tests contre le backend actif. Le Multi-Asset Deep Agentic Scan d'Ostorlab repose sur cette idée. Là où Agentic Deep Scan étudie un actif à la fois, Multi-Asset Deep Agentic Scan mène une seule investigation agentique sur des actifs liés, notamment l'application mobile, les API backend, les frontends web et le code source, au sein d'un même scan.

Figure 3 : ajout d'actifs à un Multi-Asset Deep Agentic Scan : applications mobiles issues d'un store ou sous forme de fichier, applications web, réseaux, dépôts de code et fichiers complémentaires comme les schémas d'API.

Au sein du scan, les binaires mobiles, les frontends web, les API backend et le code source alimentent tous une même étape de validation en conditions réelles, où un jeton ou une route divulgués sont testés contre le backend. Le scan se déroule en trois étapes :

1. Découverte. L'agent décompile les binaires mobiles (APK, AAB et IPA), lit les bundles JavaScript web, les source maps, les dépôts et la documentation, et exécute les applications sur des appareils Android et iOS instrumentés tout en capturant leur trafic. Il sonde aussi les emplacements OpenAPI et Swagger courants et exécute l'introspection GraphQL. Un schéma OpenAPI (Swagger 2.0 ou OpenAPI 3.x) ou GraphQL améliore la couverture dès le départ, mais il n'est pas obligatoire.
2. Corrélation. Les artefacts côté client, comme les endpoints, les URL de base, les audiences OAuth, les paramètres de requêtes et les jetons embarqués, sont rapprochés des routes et des services du backend. Un secret trouvé dans le code ou le bytecode est traité comme une piste à investiguer, pas comme une vulnérabilité confirmée.
3. Validation. Chaque chemin d'attaque plausible est confié à un agent d'exploitation, qui le teste contre le backend actif, par exemple en vérifiant si un jeton authentifie ou si un endpoint renvoie des données qu'il ne devrait pas. Les résultats validés incluent les requêtes et réponses exactes, afin que votre équipe puisse les reproduire.

De nombreux scanners de secrets signalent des chaînes qui ressemblent à des identifiants, et même ceux qui vérifient si une clé est active ne testent pas ce qu'elle permet d'atteindre via votre API. Ici, une chaîne, et la sévérité plus élevée qui l'accompagne, n'est signalée qu'une fois reproduite. Les résultats isolés sont toujours signalés pour eux-mêmes : un identifiant divulgué qui ne fonctionne pas aujourd'hui mérite quand même d'être corrigé.

Couverture des protocoles aujourd'hui :

• GraphQL : cartographié par introspection via HTTP ou par un schéma téléversé, puis testé avec des requêtes et des mutations générées.
• SOAP : testé en conditions réelles.
• gRPC : analysé à partir des définitions .proto pour détecter les risques d'autorisation et d'exposition de données. Les appels gRPC en conditions réelles et la réflexion de serveur ne sont pas encore pris en charge.
• WebSocket et abonnements GraphQL : Multi-Asset Deep Agentic Scan n'exécute pas encore de tests en conditions réelles sur les transports WebSocket.

La faille d'autorisation WebSocket citée à l'étape 6 de la checklist ci-dessous a été trouvée lors d'une évaluation ciblée distincte, réalisée par l'AI Pentest Engine d'Ostorlab ; dans un scan multi-actifs, l'autorisation WebSocket reste une vérification manuelle.

Le test autonome d'API est-il sûr à exécuter contre votre backend ?

Oui, avec des garde-fous et une cible de préproduction. Un agent qui teste des API en conditions réelles doit prouver l'impact sans causer de dégâts. Ostorlab superpose donc ses contrôles :

• Instructions des agents. Les agents démontrent l'impact par l'action sûre la plus réduite : une faille BOLA ou BFLA est démontrée par une lecture non autorisée, pas par la modification d'enregistrements, et les jetons sont vérifiés avec des requêtes en lecture seule. Les agents n'exécutent pas de commandes destructrices, n'ouvrent pas de reverse shells, n'établissent pas de persistance, ne modifient pas de données et ne révoquent pas d'identifiants.
• Un superviseur extérieur au modèle d'IA. Un programme de supervision distinct vérifie chaque appel d'outil et chaque destination par rapport au périmètre du scan avant exécution, bloque les requêtes hors périmètre et arrête le scan si un agent continue d'essayer d'en sortir. Notre post-mortem sur la dérive de périmètre d'un agent IA explique pourquoi cette couche est importante.
• Des contrôles extérieurs aux agents. Des règles de pare-feu limitent ce que les agents de scan peuvent atteindre, et le volume de requêtes est plafonné au niveau de l'hôte du scanner.

Nous recommandons toujours d'exécuter les scans multi-actifs contre un environnement de staging ou de préproduction, avec des comptes de test dédiés. Pour les API internes, un scanner on-premises s'exécute comme un conteneur dans votre infrastructure et n'ouvre qu'une connexion sortante pour recevoir des tâches et renvoyer les résultats. Pour les API de préproduction derrière un WAF ou une liste d'adresses IP autorisées, autorisez les adresses IP du scanner publiées dans la documentation d'Ostorlab. Les certificats clients ne sont pas encore un paramètre de scan : pour les API protégées par TLS mutuel, exécutez donc le scanner on-premises derrière le point où le mTLS est terminé, afin que le scanner n'ait jamais besoin de certificat client.

Comment tester votre propre pile contre les chaînes inter-actifs ?

Vous pouvez commencer avec des outils open source et quelques heures de travail ciblé. Suivez ces huit étapes pour trouver les chaînes mobile vers API, code vers API et inter-transports :

1. Listez tous les clients de l'API. Incluez chaque application mobile, frontend web, intégration partenaire et service interne qui l'appelle, ainsi que les identifiants que chacun détient.
2. Extrayez ce que les clients livrent. Décompilez les derniers builds Android (jadx -d out app.apk ou apktool d app.apk). Pour iOS, exécutez unzip app.ipa -d out sur un IPA déchiffré ; les builds de l'App Store sont chiffrés avec FairPlay, donc les chaînes du binaire ne sont pas consultables tant qu'il n'est pas déchiffré. Téléchargez les bundles JavaScript de production et les éventuelles source maps dans le même dossier. Recherchez ensuite les clés et les jetons (grep -rEai "api[_-]?key|secret|token|bearer" out/, où -a fait afficher à grep les correspondances dans les binaires compilés) et les noms d'hôtes (grep -rEaoh "https?://[a-zA-Z0-9./_-]+" out/ | sort -u). Pour un seul binaire, strings -a <binary> | grep -Ei "secret|token" fonctionne aussi.
3. Testez chaque identifiant trouvé, dans le périmètre. Pour chaque client OAuth, demandez des jetons pour les autres serveurs de ressources et scopes que vous êtes autorisé à tester (Auth0 appelle ce paramètre audience ; la RFC 8707 l'appelle resource). N'énumérez pas à l'aveugle au-delà de ce que la mission autorise. Pour chaque clé d'API, vérifiez quels hôtes et environnements du périmètre l'acceptent. Notre guide sur la recherche et la validation des secrets codés en dur montre comment vérifier ce qu'une clé divulguée permet de faire.
4. Comparez les routes découvertes avec la spécification. Une route qui apparaît dans un client ou dans le code mais pas dans le schéma OpenAPI ou GraphQL est une API fantôme potentielle. Elle peut être volontairement non documentée, dynamique ou hors périmètre : confirmez donc qu'elle est active, tournée vers l'API, non gérée et autorisée au test avant de la traiter comme telle.
5. Testez les autorisations avec une matrice de comptes rôle par tenant. Deux utilisateurs génériques ne suffisent pas. Pour chaque opération, testez l'accès avec le même rôle d'un tenant à l'autre et l'accès entre rôles au sein d'un tenant, y compris sur les endpoints de création qui acceptent un id.
6. Testez chaque transport, pas seulement HTTP. Chacun demande ses propres vérifications. Pour les WebSockets, testez l'autorisation à la connexion et à chaque opération. Pour gRPC, testez l'autorisation au niveau des méthodes et le traitement des métadonnées. Pour les webhooks, vérifiez les signatures, les horodatages, la protection contre le rejeu et le routage par tenant. Dans une évaluation GraphQL réalisée par l'AI Pentest Engine d'Ostorlab, l'API appliquait les rôles via HTTP mais acceptait des abonnements WebSocket non authentifiés.
7. Vérifiez les anciennes versions et les anciens hôtes. Appelez /v1/ là où /v2/ est la version actuelle, et essayez les hôtes de préproduction référencés dans les clients. Voici comment une incohérence de version d'API a mené à une prise de contrôle de compte.
8. Recommencez à chaque version. Un nouveau build mobile peut livrer un secret que la dernière évaluation n'a jamais vu.

Vous voulez automatiser cette checklist ? Multi-Asset Deep Agentic Scan automatise dans un même scan les étapes d'extraction, d'identifiants, de routes et d'autorisation : il récupère ce que livre votre application mobile, teste les identifiants et les routes contre l'API active, et signale les chaînes qu'il reproduit. Les vérifications WebSocket de l'étape 6 restent manuelles pour l'instant.

Comment empêcher les chaînes d'attaque inter-actifs ?

Ces correctifs sont architecturaux. Ils se situent côté serveur ou dans la façon dont les clients sont construits :

• Gardez les secrets privilégiés hors des clients. Considérez tout ce qui est livré dans une application mobile ou un bundle web comme public. Les applications natives devraient authentifier les utilisateurs avec le flux Authorization Code avec PKCE, afin de ne détenir que des jetons de courte durée propres à chaque utilisateur. Les applications de navigateur peuvent utiliser un backend-for-frontend (BFF) pour garder les jetons hors du client. Notre guide sur les secrets codés en dur présente les schémas courants.
• Limitez strictement les identifiants machine. Accordez à chaque client M2M l'accès à une seule API, avec le plus petit ensemble de scopes dont il a besoin, et déclenchez une alerte sur les demandes de jetons pour d'autres audiences.
• Retestez l'identifiant, pas seulement le chemin. Lorsque vous corrigez un identifiant divulgué, vérifiez toutes les audiences et tous les scopes qu'il peut encore atteindre, pas seulement celui que l'application utilise.
• Appliquez la propriété côté serveur pour chaque opération. Résolvez l'objet à partir de l'utilisateur authentifié, jamais à partir d'un seul id dans le corps de la requête. À la création, rejetez les identifiants d'objets existants appartenant au serveur (ou imposez une sémantique d'insertion seule) et vérifiez la propriété. Des UUID générés côté client pour les nouveaux objets peuvent convenir.
• Utilisez une seule politique d'autorisation pour tous les transports. Les WebSockets et gRPC ne peuvent pas toujours réutiliser le middleware HTTP : définissez donc la politique de façon centralisée et appliquez-la à chaque frontière : la connexion, chaque opération ou resolver, chaque message ou événement, et les intercepteurs gRPC.
• Traitez l'inventaire comme un contrôle de sécurité. Retirez les anciennes versions et les hôtes de préproduction, et gardez la spécification synchronisée avec ce que les clients appellent réellement.

Foire aux questions (FAQ)

Qu'est-ce qu'une chaîne d'attaque inter-actifs en sécurité des API ?

Une chaîne d'attaque inter-actifs combine des faiblesses présentes dans plusieurs actifs, comme une application mobile, un frontend web, le code source et une API backend. Une chaîne typique extrait un identifiant ou une route d'un client, les rejoue sous la forme d'une requête d'API valide et escalade grâce à une faille d'autorisation comme BOLA ou BFLA.

Pourquoi les scanners d'API ne détectent-ils pas les secrets codés en dur dans les applications mobiles ?

Les scanners d'API testent le backend en fonctionnement avec les identifiants et la spécification qu'on leur fournit. Ils ne décompilent pas les binaires mobiles, ne voient donc jamais les secrets compilés dans l'application, et n'ont aucune raison de tester ces secrets contre l'API.

Quelle est la différence entre l'ASPM et le scan multi-actifs ?

Les plateformes ASPM agrègent dans un seul tableau de bord les résultats de scanners distincts une fois chaque scan terminé. Le scan multi-actifs réalise une corrélation pendant le scan : une découverte dans un actif, comme un jeton dans un binaire mobile, est utilisée au cours du même scan pour exécuter des tests en conditions réelles contre l'API backend, et seules les chaînes reproduites sont signalées.

Quels risques de l'OWASP API Top 10 sont plus faciles à trouver avec un contexte client ou de code ?

Tous les risques de l'OWASP API Top 10 se corrigent côté serveur, mais Broken Object Level Authorization (API1), Broken Authentication (API2), Broken Object Property Level Authorization (API3), Broken Function Level Authorization (API5), Security Misconfiguration (API8) et Improper Inventory Management (API9) sont souvent plus faciles à découvrir ou à valider avec des identifiants, des routes ou des formats de requêtes tirés d'applications mobiles, de bundles web ou du code source.

Comment tester l'API backend d'une application mobile pour détecter une BOLA ?

Décompilez l'application pour connaître ses endpoints, ses formats d'identifiants et toute signature ou tout chiffrement des requêtes. Créez ensuite des objets avec un compte, puis lisez, modifiez et supprimez-les avec un second compte, en rejouant le format exact des requêtes de l'application. Recommencez pour les endpoints de création qui acceptent un ID d'objet.

Suffit-il de renouveler une clé d'API mobile divulguée ?

Cela dépend de la clé. Certaines clés d'API mobiles sont conçues pour être publiques et sont restreintes par application, par plateforme ou par quota : leur exposition seule n'est donc pas une compromission. Pour un secret privilégié divulgué, le renouvellement seul ne suffit pas, car le prochain build livrera le nouveau secret de la même façon. Révoquez-le et renouvelez-le, puis retirez-le du client et émettez des jetons de courte durée propres à chaque utilisateur depuis un service backend.

Pourquoi avons-nous créé le test multi-actifs ?

Nous voyions sans cesse des équipes exécuter des scanners distincts pour le code, les applications mobiles et les API, puis rapprocher les résultats à la main, alors que les chaînes qui comptaient passaient par des identifiants extraits de binaires clients.

C'est pourquoi nous avons créé Multi-Asset Deep Agentic Scan : une seule boucle qui transforme un jeton trouvé dans un binaire client en test en conditions réelles contre le backend, et ne signale que les chaînes qu'elle reproduit.

Si vous comparez plus largement les outils de test d'API, consultez notre comparatif des outils de test de sécurité des API en 2026. Pour voir ce qu'un scan multi-actifs trouve sur vos propres applications mobiles et API, réservez une démo avec notre équipe d'ingénierie sécurité.