Audit de sécurité d’une app bancaire mobile : OWASP et MobSF

La plupart des agences vendent la sécurité comme un adjectif. Cette étude de cas est une trace écrite : une vraie banque de détail, un vrai score de scanner, 48 lacunes notées, 124 tâches et une liste honnête de ce qui reste ouvert.

L’app Android de la banque repose sur un SDK bancaire en marque blanche. Lorsque l’analyse menée par la banque elle-même a renvoyé un score de sécurité MobSF de 48 sur 100, la question n’était pas seulement de savoir comment faire monter ce chiffre. Il s’agissait de comprendre ce qu’il signifiait réellement, quelles lacunes étaient réelles et comment les corriger d’une manière que l’équipe sécurité de la banque puisse vérifier.

Dans cet article, nous détaillons comment l’audit a été mené, ce que la remédiation comprenait, comment les correctifs ont été vérifiés et ce qui reste ouvert.

Le point de départ

Un score de 48/100 semble alarmant, mais un score brut, à lui seul, dit peu de chose. Avant tout correctif, nous devions répondre à trois questions :

Pouvons-nous reproduire le score ? Si nous n’obtenons pas le même résultat, nous ne pourrons pas prouver une amélioration par la suite.
Quels constats sont réels ? Les scanners mélangent de vraies failles avec du bruit lié à la configuration du build et des faux positifs.
Qu’est-ce que le scanner ne voit pas ? Les outils automatisés voient le binaire, pas la logique. Les parcours d’authentification, la gestion des clés et le stockage des données exigent une revue humaine.

📌 À retenir :

Un score de scanner marque le début d’un audit, pas sa fin. Le résultat utile est une liste de lacunes réelles et notées, chacune prise en charge par quelqu’un.

Comment l’audit de sécurité a été mené

Phase 1 : reproduire le score du scanner

Nous avons refait l’analyse et reproduit le résultat de la banque. Puis nous avons réparti chaque point perdu par l’app en catégories. Le constat qui a le plus surpris la banque : 6 à 7 des 52 points manquants venaient uniquement du type de build — l’analyse avait été lancée sur un build debug et non sur le build release que les utilisateurs installent réellement. Et deux contrôles que le scanner avait marqués comme sécurisés se sont révélés être des faux positifs.

Phase 2 : audit manuel selon l’OWASP Mobile Top 10 (2024)

Nous avons passé l’app en revue catégorie par catégorie selon l’OWASP Mobile Top 10 (2024), de l’utilisation inappropriée des identifiants (M1) et de la sécurité de la chaîne d’approvisionnement (M2) jusqu’au stockage de données non sécurisé (M9) et à la cryptographie insuffisante (M10). Chaque lacune a reçu un score CVSS, afin que la banque puisse prioriser selon la gravité plutôt que selon le caractère plus ou moins alarmant d’un constat.

Résultat : 48 lacunes notées CVSS.

Phase 3 : un plan de remédiation chiffré

Les 48 lacunes ont été découpées en 124 tâches suivies. Chaque modification s’accompagnait d’une courte note écrite sur la menace et la décision : quel est le risque, quelle option nous avons retenue, ce que nous avons écarté et pourquoi. Lorsque la banque a décidé d’accepter un risque plutôt que de le corriger, cette décision a elle aussi été consignée.

Phase 4 : remédiation et durcissement

En parallèle de la correction des constats, nous avons conçu et testé un ensemble de contrôles à l’exécution et anti-abus, notamment :

Protection contre les overlays en trois couches, complétée par un classifieur des abus du service d’accessibilité.
Connexion biométrique liée à un CryptoObject, pour qu’un callback intercepté ne puisse pas simuler une connexion réussie.
Détection du root, de Frida et des émulateurs, avec 35 tests pour la détection d’émulateur par valeurs exactes et aucun faux positif sur les Chromebooks.
Anti-repackaging via une vérification du certificat de signature et une vérification de l’installateur.
Effacement du presse-papiers après 60 secondes pour les valeurs sensibles copiées.
TLS 1.3 uniquement pour le trafic réseau.
Chiffrement d’enveloppe des données locales au lieu de SQLCipher, ce qui a économisé 6,5 Mo de code natif pour un coût d’environ 1 ms par écran.

Comment les correctifs ont été vérifiés

Des correctifs testés uniquement par le développeur sont des affirmations, pas des preuves. La vérification s’est faite en deux couches.

Un pack de sécurité QA indépendant

L’équipe QA a constitué un pack de vérification de sécurité de 79 vérifications scriptées couvrant 45 tickets de sécurité. Chaque vérification confirme qu’un contrôle précis fonctionne sur un vrai build.

Tester les tests

Nous avons ensuite testé le pack QA lui-même par tests de mutation : casser volontairement des contrôles de sécurité dans des builds de test et confirmer que les vérifications détectent chaque défaillance. Le runner a détecté tous les mutants. Tout aussi important, 13 de ces mutants avaient survécu aux propres tests des développeurs — exactement les lacunes qu’une vérification indépendante est là pour trouver.

Des preuves de sécurité de la chaîne d’approvisionnement dans la CI

Chaque release est désormais livrée avec un SBOM CycloneDX, et les dépendances sont analysées avec OWASP Dependency-Check. La première analyse a produit 1 388 correspondances CVE brutes. Chacune a été triée et neutralisée avec une justification écrite et datée, et aucune ne s’est révélée être une vraie vulnérabilité dans l’APK de release.

Les résultats en un coup d’œil

Élément	Résultat
Score MobSF de départ	48/100, reproduit
Points expliqués par le seul type de build	6 à 7 sur 52
Coches « sécurisé » du scanner qui étaient fausses	2
Lacunes notées CVSS	48
Tâches de remédiation suivies	124
Vérifications de sécurité QA	79 vérifications sur 45 tickets
Correspondances CVE brutes triées	1 388 → 0 réelle
Durée	Environ neuf semaines

Ce qui reste ouvert

Nous publions les lacunes avec les résultats, car c’est ce qui rend le reste crédible :

Pas encore de nouvelle notation finale ni de pentest externe. Nous ne revendiquons ni note MobSF finale, ni test d’intrusion réussi, ni conformité complète à l’OWASP MASVS.
Le certificate pinning est prêt et attend la politique de rotation des clés de la banque avant d’être activé.
L’analyse des dépendances signale mais ne bloque pas encore les releases en cas de constats de gravité élevée.

Le Mobile Security Teardown de Mobian

Cette mission est devenue le modèle de notre Mobile Security Teardown : deux semaines, prix forfaitaire. Nous reproduisons votre score de scanner, menons un audit manuel selon l’OWASP Mobile Top 10 (2024), attribuons un score CVSS à chaque lacune et vous remettons un plan de remédiation chiffré que votre équipe — ou la nôtre — peut exécuter.

Chez Mobian, nous ne sommes pas un cabinet de conformité et nous ne vous dirons pas qu’un audit vous rend conforme. Ce que nous livrons, ce sont des preuves que votre auditeur peut suivre, jusqu’au fichier et à la ligne.

Conclusion

Un score MobSF de 48/100 a indiqué à la banque que quelque chose n’allait pas, mais pas quoi. Reproduire le score, auditer manuellement selon l’OWASP, noter chaque lacune et vérifier chaque correctif a transformé un chiffre alarmant en 124 tâches attribuées et traçables. Si quelqu’un — une banque partenaire, un auditeur, un régulateur — a déjà trouvé un problème dans votre app mobile, c’est par là qu’il faut commencer.

Questions fréquentes

Que couvrait l’audit de sécurité ?

Quatre volets : la reproduction de l’analyse MobSF réalisée par la banque, un audit manuel de l’app Android sur les dix catégories de l’OWASP Mobile Top 10 (2024), un score CVSS pour chaque lacune identifiée et un plan de remédiation chiffré. La remédiation et la vérification QA indépendante ont suivi dans le cadre de la même mission.

L’app a-t-elle passé un test d’intrusion après les correctifs ?

Nous ne l’affirmons pas. Aucun test d’intrusion externe ni aucune nouvelle notation MobSF finale n’ont encore été réalisés. Ce que nous pouvons montrer, c’est une trace datée et chiffrée : 48 lacunes notées, 124 tâches suivies et un pack QA qui vérifie les correctifs et a lui-même été testé sur des builds volontairement cassés.

Un score MobSF suffit-il pour juger de la sécurité d’une app ?

Non. Dans ce projet, 6 à 7 des 52 points manquants venaient uniquement de l’analyse d’un build debug au lieu d’un build release, et deux contrôles que le scanner avait marqués comme sécurisés étaient des faux positifs. Un score est le point de départ d’un audit manuel, pas un verdict.

Ce travail rend-il une app conforme à DORA ou à d’autres réglementations ?

Mobian n’est pas un cabinet de conformité, et un audit ne rend pas à lui seul une app conforme. Ce qu’il produit, ce sont des preuves qu’un auditeur peut suivre : des constats notés, une décision écrite pour chaque modification, une remédiation au niveau des fichiers et des résultats QA indépendants. Ce sont vos équipes conformité et juridique qui déterminent ce que ces preuves couvrent.

Les mêmes contrôles peuvent-ils protéger des apps crypto ou de jeu ?

Beaucoup d’entre eux, oui. La protection contre les overlays, la détection des abus d’accessibilité, la détection du hooking et des émulateurs et les contrôles anti-repackaging ciblent des schémas d’abus qui se ressemblent dans toutes les apps qui gèrent de l’argent. Nous n’avons pas développé de fonctionnalités propres à une niche, comme la conservation des clés ou la géolocalisation certifiée, et nous le disons d’emblée.

Étude de cas : d’un score MobSF de 48/100 à 124 correctifs de sécurité suivis en neuf semaines