Les néobanques indépendantes en retard sur la sécurité des applications : 79 % contre 51 %

Dans notre étude 2026, les néobanques font moins bien que les banques traditionnelles en matière de sécurité des applications mobiles. Pour les néobanques indépendantes, l'écart est considérable : 79,3 % de leurs applications présentent au moins un résultat de sévérité élevée ou critique, contre 51,2 % des applications de banques traditionnelles. Soit un écart de 28,1 points de pourcentage.

Les banques construites autour d'une application devraient avoir toutes les raisons de la soigner. Pourtant, les néobanques indépendantes intègrent des identifiants dans leurs applications plus de deux fois plus souvent que les banques traditionnelles, tout en les devançant sur les passkeys et l'attestation de l'application. Des fonctions de sécurité modernes côtoient des faiblesses élémentaires.

Ces résultats proviennent du Rapport 2026 sur la sécurité des applications bancaires mobiles d'Ostorlab, qui couvre 2 686 applications de 487 banques dans 64 pays. Le clivage le plus net sépare les néobanques indépendantes de toutes les autres banques.

Un écart de 28 points. L'actionnariat compte.

Regrouper toutes les néobanques masque l'essentiel. Tous types confondus, 61,1 % de leurs applications présentent un résultat de sévérité élevée ou critique. Les distinguer selon leur actionnariat fait apparaître deux situations très différentes :

Les néobanques détenues par une banque ressemblent beaucoup à leur maison mère. Ce sont les néobanques indépendantes qui expliquent l'écart.

Le groupe indépendant est restreint : 29 applications de 10 banques, dont environ un tiers provient d'une seule banque. Le rapport constate que l'écart persiste lorsque chaque banque reçoit le même poids et lorsque la répartition des plateformes est prise en compte, mais son ampleur reste indicative. La différence porte sur les résultats de sévérité élevée ; les résultats critiques apparaissent à des fréquences comparables dans les trois groupes. Il s'agit de résultats de scanner dans les applications distribuées, pas de taux de compromission mesurés.

Plus de passkeys. Plus de secrets exposés.

Les néobanques indépendantes sont en avance sur certains contrôles que les équipes de sécurité souhaitent voir les banques adopter. 37,9 % intègrent une API de passkeys, contre 4,6 % des applications de banques traditionnelles. 48,3 % utilisent l'attestation de l'application ou de l'appareil, contre 19,9 %.

Pourtant, 48,3 % intègrent des identifiants autres que les clés d'API Google, contre 19,8 % des applications de banques traditionnelles. Des résultats de sévérité élevée ou critique liés à la prise de contrôle de compte via OAuth apparaissent dans 24,1 % des applications, contre 6,1 % : presque quatre fois plus souvent.

Une passkey peut protéger une connexion contre le hameçonnage. Elle ne peut ni supprimer une clé privée embarquée dans l'application, ni corriger un autre parcours OAuth. Ajouter un contrôle solide ne compense pas une faiblesse ailleurs. Pour l'équipe de sécurité d'une banque, la question utile est de savoir si tout le parcours, de la connexion au paiement, tient bon.

Les banques traditionnelles ont peu de raisons de se réjouir

Le groupe qui obtient les meilleurs résultats présente tout de même des résultats graves dans environ la moitié de ses applications. Sur l'ensemble de l'échantillon, 51,5 % présentent un résultat de sévérité élevée ou critique, 20,3 % intègrent un identifiant qui devrait rester secret et 41,1 % embarquent un composant tiers présentant une vulnérabilité publiée.

Ces identifiants comprennent des clés privées, des clés cloud et des jetons de service. Une application est distribuée sur les appareils des clients ; tout ce qu'elle contient peut être extrait. Un secret nécessaire à la protection des services de la banque ne devrait pas dépendre de sa capacité à y rester caché.

Les clés d'API Google sont comptabilisées séparément. Beaucoup sont destinées à être distribuées avec Maps ou Firebase ; en trouver une ne prouve donc pas une fuite. Leur risque dépend des restrictions appliquées, que cette étude n'a pas testées. Aucun des identifiants trouvés n'a été essayé.

L'application de la banque peut devenir l'outil de l'attaquant

Des campagnes récentes montrent pourquoi l'intégrité des applications compte. GoldFactory modifie des applications bancaires authentiques. Gigabud les clone dans un profil professionnel masqué. Hirudo remplace la véritable application par une copie modifiée. L'interface familière peut rester intacte tandis que le code sous-jacent sert l'attaquant.

Pourtant, 79,8 % des applications ne présentent aucune attestation de l'application ou de l'appareil, et seules 22,3 % des applications Android détectent les outils de prise de contrôle à distance utilisés pour commettre une fraude depuis le téléphone d'une victime. L'attestation de l'application peut aider à repérer une copie altérée, mais elle n'aide la banque que si le serveur agit en fonction du résultat. L'application seule ne permet pas de vérifier si le serveur impose ce contrôle.

La biométrie exige la même vigilance. Le scanner a signalé des parcours de connexion biométrique contournables dans 35,1 % des applications Android. La robustesse d'une demande d'empreinte digitale dépend de l'opération qu'elle protège : un parcours qui se contente de vérifier un résultat oui ou non peut être court-circuité. Les actions sensibles doivent exiger la clé cryptographique déverrouillée par la vérification biométrique.

Les enjeux financiers sont déjà visibles. La banque mobile a concentré 301,8 millions de livres, soit 52 %, des pertes liées aux escroqueries par virement autorisé au Royaume-Uni en 2025, selon UK Finance. Ces pertes illustrent les enjeux de manière indépendante ; elles ne sont pas attribuées aux résultats de cette étude.

Ce qui doit changer avant la prochaine version

Pour les dirigeants bancaires, cette comparaison appelle des preuves que les protections fonctionnent ensemble. Pour les équipes d'ingénierie et de sécurité, commencez par ces vérifications, tirées des recommandations du rapport et rattachées dans celui-ci à OWASP MASVS :

1. Retirez les secrets de l'application distribuée. Conservez les clés privées et les identifiants de service sur le serveur. Fournissez à l'application des jetons à courte durée de vie et aux accès limités.
2. Corrigez les failles connues des dépendances. Tenez une nomenclature logicielle pour chaque version et fixez un délai de correction pour les composants critiques.
3. Testez le parcours de la connexion au paiement. Liez les actions sensibles à des clés protégées par le matériel, vérifiez les parcours OAuth et proposez les passkeys. Testez si un contrôle peut être contourné, pas seulement si son API apparaît dans le code.
4. Faites de l'intégrité de l'application une décision du serveur. Validez les verdicts de Play Integrity ou d'App Attest sur le serveur et agissez en cas d'échec. Testez les protections à l'exécution face aux outils actuels des attaquants, sur de vrais appareils.
5. Tenez compte du risque de l'appareil au moment décisif. Vérifiez le niveau de correctifs à la connexion et limitez les actions à haut risque sur les appareils non corrigés. Détectez les outils de prise de contrôle à distance avant qu'ils ne transforment une session légitime en fraude.

La question à poser lors de la revue de la prochaine version est concrète : l'équipe peut-elle démontrer qu'un attaquant ne peut pas sauter les vérifications qui protègent un compte ou un paiement ?

Lisez le rapport complet pour découvrir la comparaison par type de banque, les tableaux par pays, les quatre études de cas d'attaques et les huit actions recommandées. Testez ces contrôles dans votre propre application avec Ostorlab pour la banque.

Ce que l'étude a mesuré

Entre le 28 octobre et le 5 novembre 2026, nous avons recensé 2 841 fiches d'applications bancaires et analysé 2 686 applications sur Android, iOS et HarmonyOS. L'échantillon couvre 487 banques, dont 29 banques d'importance systémique mondiale, et représente cinq fois celui de notre édition 2025. L'échantillon et la méthode ont changé ; les deux éditions ne permettent donc pas de dégager une tendance d'une année sur l'autre.

Chaque application a fait l'objet d'une analyse statique, d'un scan rapide automatisé et de seize vérifications des contrôles d'authentification et de paiement, accompagnés d'un examen des données publiques de la banque. Un résultat signifie que le scanner a trouvé une correspondance avec une règle dans le paquet distribué, pas qu'il a prouvé l'exploitabilité. Aucune application n'a été attaquée, aucune connexion n'a été testée et aucun identifiant découvert n'a été utilisé. Les protections côté serveur peuvent être invisibles avec cette méthode. Les vérifications nécessitant un code lisible excluent les applications dont le code est empaqueté : les résultats globaux sur les passkeys portent sur 2 586 applications, et ceux sur l'attestation sur 2 602. Les résultats sont agrégés ; aucune banque ni application n'est nommée.