Comment une fintech en série B a corrigé 23 failles critiques d’API avant sa prochaine levée de fonds

Mission représentative. Détails du client anonymisés et éléments spécifiques modifiés sous NDA.

Changez un chiffre dans une URL et lisez les transactions bancaires d’un inconnu. C’est la première chose que nous avons trouvée, le deuxième jour, sur une API de fintech qui déplace de l’argent réel. La faille est restée non corrigée pendant toute l’année où un scan de vulnérabilités “propre” avait dormi dans leur dossier de preuves.

Le client était une fintech en série B, une quarantaine d’ingénieurs, à six semaines de l’ouverture d’un tour de série C. Son investisseur principal voulait une revue de sécurité par un tiers avant de signer le term sheet. Son produit était presque entièrement une API : une application mobile et un tableau de bord web partenaire qui parlaient au même ensemble d’endpoints REST. Il a donc demandé un test d’intrusion d’API, pas un scan réseau ni un rapport à cocher.

Cette distinction, c’est toute l’histoire. Les problèmes que nous avons trouvés étaient exactement le genre que les outils automatisés ignorent complètement. Au bout du compte, nous avions signalé 23 problèmes critiques et élevés, et la grande majorité étaient des failles d’autorisation. L’API faisait bien plus confiance à l’appelant qu’elle n’aurait dû.

Points clés à retenir

• Les failles d’API les plus dommageables dans la fintech sont des bugs d’autorisation (BOLA/IDOR et défaut d’autorisation au niveau des fonctions), pas l’injection ni la mauvaise configuration. Les scanners passent à côté de la quasi-totalité d’entre elles.
• Dans cette mission représentative, nous avons signalé 23 problèmes critiques et élevés en six semaines, dont une exposition de données entre comptes, un chemin de mass assignment vers un rôle admin, et des endpoints OTP sans limitation de débit.
• Le test d’intrusion d’API consiste à tester avec plusieurs rôles d’utilisateurs réels, à comparer ce que chaque token est autorisé à toucher, et à détourner la logique métier. Ce n’est pas lancer une liste de requêtes sur un seul endpoint.
• Corriger l’autorisation au niveau de l’objet (cet utilisateur possède-t-il cette ressource ?) a fermé la plupart des failles critiques. Le nouveau test a confirmé que les correctifs tenaient.
• L’entreprise a passé la due diligence technique sans qu’aucun constat de sécurité ne bloque la levée de fonds.

Le contexte : une API qui déplaçait de l’argent et faisait confiance à tout le monde

La stack était familière. Une API Node et Express derrière une passerelle, PostgreSQL, des tokens d’accès JWT, un client mobile et un tableau de bord partenaire. Environ 180 endpoints documentés, plus une poignée qui ne figuraient pas du tout dans la documentation. Il y en a toujours. Les utilisateurs pouvaient détenir des soldes, envoyer des virements, inviter des coéquipiers et relier des comptes bancaires externes.

Leur propre lecture du produit était qu’il était “plutôt solide”. Ils avaient un WAF. Ils faisaient tourner un scanner de dépendances en CI. Un prestataire précédent leur avait remis un scan de vulnérabilités à l’air propre l’année d’avant.

Ce scan est un bon exemple de pourquoi un scan n’est pas un pentest. Il a confirmé que leur configuration TLS et les versions de leurs bibliothèques étaient correctes. Il ne disait rien sur la question de savoir si l’utilisateur A pouvait lire les transactions de l’utilisateur B, ce qui s’est avéré être tout l’enjeu.

Notre approche : rôles, tokens, et ce que chacun est autorisé à toucher

Nous l’avons cadré comme un test gray-box. Ils nous ont donné la documentation de l’API, une collection Postman, et plusieurs comptes de test répartis sur tous les rôles : deux utilisateurs standard dans des organisations distinctes, un admin d’organisation, un analyste en lecture seule et un compte de tableau de bord partenaire. Disposer de plusieurs comptes par rôle est l’élément le plus important pour un vrai test d’autorisation. On ne peut pas prouver qu’un utilisateur atteint des données qu’il ne devrait pas sans les données d’un second utilisateur à aller chercher.

L’installation de travail n’avait rien de glamour. Burp Suite comme proxy pour le trafic mobile et le tableau de bord, avec la session de chaque compte enregistrée afin de pouvoir rejouer n’importe quelle requête sous n’importe quelle identité. Deux ou trois extensions Burp pour comparer les réponses entre les rôles. ffuf pour la découverte d’endpoints et de paramètres. Puis beaucoup d’édition manuelle de requêtes. La plupart des vrais constats venaient d’une lecture attentive des réponses, pas de l’outillage.

La première passe se contente de cartographier la surface : chaque endpoint, chaque paramètre, chaque format d’ID, et quel rôle est censé y accéder. La seconde passe est la plus intéressante. Nous prenons une requête qui appartient légitimement à l’utilisateur A, la rejouons avec le token de l’utilisateur B, puis avec le token de l’analyste, puis sans aucun token, et observons ce qui revient.

À quoi ressemblait concrètement “tester l’API” ici

Prenons l’endpoint des transactions. Il acceptait un ID de compte numérique dans le chemin :

GET /v2/accounts/48213/transactions HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-A-token>

Changez 48213 en 48214, gardez le token de l’utilisateur A, et l’API renvoyait l’historique complet des transactions d’un autre client. C’est du Broken Object Level Authorization, classé API1 dans l’OWASP API Security Top 10, et le même problème de fond que l’on appelle IDOR (CWE-639). Les ID étaient des entiers séquentiels, donc parcourir l’ensemble de la base clients était trivial. Premier constat critique déposé, le deuxième jour.

Ce n’était pas un cas isolé. Le même contrôle de propriété manquant est réapparu sur les relevés, sur l’endpoint qui renvoyait les détails masqués d’un compte bancaire relié, et sur un téléchargement de facture PDF qui prenait un ID de document et ne faisait aucun contrôle du tout. Une seule classe de faille, plusieurs endpoints. Le code authentifiait le token mais ne demandait jamais si le propriétaire du token possédait réellement l’objet demandé.

Ce que nous avons trouvé : les points saillants

Au-delà des bugs au niveau des objets, quelques constats méritent d’être soulignés car ils reviennent encore et encore sur les API de fintech.

Mass assignment vers un rôle admin. L’endpoint permettant de mettre à jour son propre profil acceptait un corps JSON et le liait directement au modèle utilisateur. Il documentait name et email. Il acceptait aussi silencieusement role. La requête ci-dessous faisait passer un utilisateur standard au rang d’admin d’organisation :

PATCH /v2/users/me HTTP/1.1
Authorization: Bearer <standard-user-token>
Content-Type: application/json

{"name":"Jordan","role":"admin"}

C’est du mass assignment (CWE-915), la faille que l’actuel OWASP API Security Top 10 range sous Broken Object Property Level Authorization. Associée à la suivante, elle devient particulièrement dangereuse.

Défaut d’autorisation au niveau des fonctions. Les endpoints réservés aux admins qui listaient tous les utilisateurs de l’organisation et modifiaient les permissions des membres vérifiaient que vous étiez authentifié, mais pas que vous étiez admin. Un utilisateur standard pouvait les appeler directement. Associez cela au bug de mass assignment et un unique compte à faibles privilèges disposait d’un chemin tout tracé vers le contrôle total d’une organisation.

Endpoints OTP et de réinitialisation de mot de passe sans limitation de débit. L’endpoint de vérification du code à usage unique acceptait un nombre illimité de tentatives. Un code à six chiffres sans verrouillage ni throttling n’est pas un second facteur. C’est un ralentisseur. Nous avons trouvé un code valide par force brute en quelques minutes depuis une seule IP. Le flux de réinitialisation de mot de passe présentait la même lacune.

Un JWT à qui l’on faisait trop confiance. Le token d’accès portait le rôle de l’utilisateur et l’ID d’organisation sous forme de claims, et au moins un service prenait des décisions à partir de ces claims sans les revérifier côté serveur. Les tokens avaient une longue durée de vie et il n’y avait pas de révocation côté serveur, si bien qu’un token fuité restait exploitable bien trop longtemps.

Rien de tout cela n’a nécessité un outillage exotique. Il a fallu un second compte et quelqu’un prêt à se demander ce qui se passe si j’envoie cette requête en me faisant passer pour la mauvaise personne.

Le résultat

Nous avons livré les constats au fil de l’eau plutôt que de tout déverser à la fin. C’est ainsi que nous menons chaque mission à durée limitée. Les problèmes de BOLA sont allés à leur équipe le deuxième jour afin que les ingénieurs puissent commencer à corriger pendant que nous continuions à tester. Chaque constat était livré avec la requête exacte pour le reproduire, l’impact en langage clair et un correctif précis.

Leur équipe a réagi vite. Les correctifs étaient pour l’essentiel structurels : un middleware de contrôle de propriété qui vérifiait que l’utilisateur authentifié possédait bien l’objet indiqué dans le chemin, de vrais contrôles de rôle sur chaque route privilégiée, une allow-list des champs modifiables au lieu de lier le corps entier, ainsi qu’une limitation de débit et un verrouillage sur les endpoints d’authentification. Des durées de vie de token plus courtes et une liste de révocation ont réglé le problème du JWT.

Nous avons mené un nouveau test complet contre les correctifs. Les 23 constats critiques et élevés étaient tous fermés et vérifiés, et le nouveau middleware de propriété avait également intercepté deux problèmes de moindre gravité que nous avions signalés. Lorsque la due diligence technique de l’investisseur a eu lieu quelques semaines plus tard, rien de lié à la sécurité n’a bloqué le tour de table. C’était tout l’enjeu : le trouver avant qu’un acteur hostile, ou l’auditeur d’un acquéreur, ne le trouve à votre place.

Comment CyberXplore vous aide

C’est l’essence même de ce que fait notre service de tests d’intrusion d’API : un test manuel et sensible aux rôles des endpoints qui font réellement tourner votre activité, mis en correspondance avec l’OWASP API Security Top 10, avec des étapes de reproduction exploitables par un développeur et un nouveau test pour confirmer que les correctifs tiennent. Si vous vous dirigez vers une levée de fonds, une intégration partenaire ou une échéance de conformité et que votre produit est une API, c’est exactement là que cela porte ses fruits. Demandez un devis et parlez-nous de votre stack et de votre calendrier.

FAQ

Pourquoi un scanner de vulnérabilités ne peut-il pas trouver ces failles d’API ?

Les scanners sont bons sur les problèmes connus : bibliothèques obsolètes, TLS faible, en-têtes manquants, certains motifs d’injection. Les failles d’autorisation comme BOLA dépendent du contexte métier. Un scanner n’a aucune idée que le compte 48214 appartient à un autre client, donc une réponse 200 lui semble normale. Les trouver exige un humain qui compare ce à quoi différents utilisateurs réels ont le droit d’accéder, et c’est là tout le principe du test d’intrusion d’API.

Combien de temps prend un test d’intrusion d’API ?

Cela dépend du nombre d’endpoints, du nombre de rôles et de la quantité de logique métier en jeu. Un test d’API ciblé sur une fintech de taille moyenne représente généralement une à trois semaines de tests actifs, plus un nouveau test. La mission décrite ici a représenté environ deux semaines de tests dans une fenêtre de six semaines qui incluait la correction et le nouveau test.

Qu’est-ce que le BOLA et pourquoi est-ce le principal risque des API ?

Le BOLA (Broken Object Level Authorization) désigne le cas où une API vérifie que vous êtes connecté mais pas que l’objet précis que vous avez demandé vous appartient. Il occupe la première place de l’OWASP API Security Top 10 parce qu’il est courant, trivial à exploiter en changeant un ID dans une requête, et qu’il expose souvent les données de tous les utilisateurs d’un coup. C’est le même problème de fond que l’IDOR (CWE-639).

Avez-vous besoin d’un accès à la production ou au code source ?

Ni l’un ni l’autre n’est strictement requis, mais les deux aident. La plupart de nos missions sont en gray-box : nous travaillons sur un environnement de staging ou proche de la production avec plusieurs comptes de test couvrant tous les rôles et un accès à la documentation de l’API. Le code source peut accélérer l’analyse des causes racines, mais les constats critiques dans ce cas provenaient de tests de requêtes en gray-box, pas d’une revue de code.

Que recevons-nous à la fin ?

Un rapport qui commence par le risque, liste chaque constat avec sa gravité, les étapes exactes de reproduction et un correctif concret, ainsi qu’un nouveau test confirmant ce qui a réellement été fermé. Nous livrons les constats critiques à mesure que nous les trouvons afin que votre équipe puisse commencer à remédier avant la fin de la mission, et nous restons disponibles pour discuter des correctifs avec vos ingénieurs.

Nous sommes en phase de pré-levée. Un pentest en vaut-il la peine dès maintenant ?

Oui, et c’est souvent le meilleur moment. Les investisseurs mènent de plus en plus une due diligence technique, et l’auditeur d’un acquéreur qui découvre une faille d’autorisation critique au stade du term sheet, c’est une conversation bien pire que de la corriger discrètement en amont. Un rapport de nouveau test propre et vérifié est un signal fort que l’équipe prend la sécurité au sérieux.