Applications mobiles africaines : l’API ne doit jamais faire confiance à son propre APK

Ce que l’enquête japonaise a réellement observé

Le 21 octobre 2026, le centre japonais de réponse aux incidents informatiques JPCERT/CC a publié les résultats d’une enquête menée avec plusieurs organisations après des accès non autorisés et des fuites de données au Japon. Sur des serveurs associés aux opérations étudiées, les analystes ont retrouvé des fichiers APK, des outils de rétro-ingénierie Android et Flutter comme jadx et Blutter, ainsi que des scripts destinés à tester des interfaces de programmation applicative (API), notamment pour des failles de type SSRF. Certaines applications analysées visaient aussi des utilisateurs hors du Japon.

JPCERT/CC indique que les attaquants ont utilisé l’intelligence artificielle pour rechercher des vulnérabilités connues et conduire des attaques contre des API. La publication apporte surtout des éléments techniques concrets : extraction d’applications, reconstruction de leur logique, identification des points d’accès serveur et automatisation des tests. Elle ne publie pas la liste complète des victimes ni une mesure permettant d’attribuer chaque action à l’IA. Il faut donc retenir l’évolution opérationnelle sans transformer « assisté par IA » en explication universelle.

Le point essentiel est plus simple. Une application mobile distribuée au public se trouve sur un appareil que l’éditeur ne contrôle pas. Son code peut être extrait, observé, modifié et exécuté hors du parcours prévu. L’obfuscation ralentit l’analyse; elle ne crée pas une frontière de confiance.

L’APK n’est pas une preuve d’autorisation

De nombreuses applications supposent encore qu’une requête est légitime parce qu’elle contient un en-tête, une signature ou une clé intégrée au client officiel. Or un secret placé dans un APK peut finir par être découvert. Un attaquant peut alors construire son propre client, reproduire le format des requêtes et appeler directement l’API sans passer par les écrans, limites ou contrôles de l’application.

Une signature de requête conserve une valeur lorsqu’elle repose sur une clé liée à l’utilisateur ou au terminal, correctement protégée et révocable. Elle devient fragile si tous les exemplaires de l’application partagent le même secret. Le serveur doit toujours authentifier l’identité réelle, vérifier son droit sur l’objet demandé et réévaluer l’autorisation pour chaque action. Changer un identifiant de client dans une URL ne doit jamais permettre d’accéder au dossier d’un autre utilisateur.

L’avis conjoint publié le 12 novembre par la PDPC et la Cyber Security Agency de Singapour insiste précisément sur ces risques. Il décrit l’exposition involontaire d’API internes, les identifiants par défaut, les jetons compromis, les autorisations excessives et le Broken Object Level Authorization, ou BOLA. Il rappelle aussi qu’une requête utilisant un identifiant valide peut rester malveillante et qu’une extraction massive peut se confondre avec le trafic normal.

Pourquoi l’Afrique est directement concernée

L’Afrique est un marché mobile-first. Les applications donnent accès au mobile money, aux banques, aux prêts, à l’assurance, au commerce, à la santé, aux impôts et aux services d’identité. Dans beaucoup de projets, l’interface Android est visible tandis que l’API concentre la donnée et la décision. Une faiblesse serveur peut donc exposer plusieurs versions de l’application et tous les utilisateurs en même temps.

Le rapport Mobile Money 2026 de la GSMA recense 1,2 milliard de comptes enregistrés et 341 millions de comptes actifs sur trente jours en Afrique subsaharienne. Cette échelle transforme une erreur d’autorisation en risque systémique. Le sujet ne concerne pas seulement les grandes plateformes : une fintech livrée rapidement, un portail public développé par un prestataire ou une application de santé reliée à une ancienne API peuvent conserver des routes oubliées et des secrets communs.

Aucune source examinée n’établit que les applications africaines ont été visées dans l’opération japonaise. Le rapprochement repose sur une architecture commune et vérifiable, pas sur une victime inventée. Les équipes africaines peuvent agir avant d’apparaître dans un rapport d’incident.

Tester le serveur comme si l’application était hostile

Le test utile commence par supposer que l’attaquant connaît toutes les routes visibles dans l’APK. Il faut créer deux comptes de contrôle et vérifier que le premier ne peut jamais lire, modifier ou supprimer les objets du second, même en changeant les identifiants, les paramètres, le type de contenu ou l’ordre des appels. Les contrôles doivent couvrir les fonctions métier : consultation de solde, changement de numéro, ajout de bénéficiaire, demande de prêt, téléchargement de document et action administrative.

Les environnements de test et de préproduction doivent être séparés de la production. Une API UAT exposée avec des données copiées, des identifiants partagés ou une route réseau vers le système réel peut devenir un accès moins surveillé. Les anciens endpoints doivent être inventoriés puis désactivés; les retirer de l’application ne suffit pas.

Les journaux doivent relier chaque requête à l’utilisateur, au client, à l’objet demandé, à la décision d’autorisation et au volume retourné, sans recopier inutilement les données sensibles. Les alertes doivent rechercher l’énumération séquentielle, les accès à de nombreux comptes, les exports inhabituels, les échecs répétés et les appels provenant d’un client non attendu. La limitation de débit réduit l’extraction mais ne remplace pas une autorisation correcte.

Une priorité de conception, pas un audit tardif

Les contrats avec les développeurs et intégrateurs doivent exiger un inventaire d’API, des tests d’autorisation, une gestion des secrets, une journalisation exploitable et une procédure de révocation. L’organisation cliente doit pouvoir obtenir les résultats et refaire les tests après une migration ou une intégration tierce.

L’enseignement venu du Japon n’est pas que Flutter ou Android seraient intrinsèquement dangereux. Il est qu’un client mobile ne peut protéger seul une API. Pour les services africains, la règle d’architecture doit être nette : considérer l’application comme observable par l’adversaire, conserver les secrets durables hors du client et faire du serveur l’autorité finale sur chaque donnée et chaque action.

— ◆ —