Logo Ostorlab
Tarifs
Partenaires
ConnexionRéserver une démo
Réserver une démo

Édition 2026

Sécurité des applications bancaires mobiles2026

Les applications des néobanques indépendantes sont plus souvent jugées à haut risque que celles des banques traditionnelles : 79 % contre 51 %.

  • Pas jugée à haut risque
  • Jugée à risque élevé ou critique
  • 29 applications de 10 néobanques indépendantes, face à toutes les autres applications bancaires scannées.

Sécurité des applications bancaires mobiles

Au cœur de 2 690 applications bancaires

Nous avons examiné 2 690 applications bancaires sur Android, iOS et HarmonyOS, de 500 banques. Deux sources : les applications elles-mêmes, lues et scannées par Ostorlab, et les informations publiques comme les pages des stores, les sites des banques et les rapports de menaces.

Voir les principaux résultatsRéserver une démo
Couverture du rapport 2026 sur la sécurité des applications bancaires mobiles

Trois questions auxquelles ce rapport répond

Comment nous avons testé
  1. Votre banque remarquerait-elle une fausse copie de son application ?
  2. Si l’on vous vole votre téléphone, pouvez-vous bloquer votre compte sans lui ?
  3. Que peuvent apprendre les attaquants sans même ouvrir l’application ?

Principaux résultats

Les principaux résultats en un coup d’œil

  1. Appels frauduleux11 %des applications ont tous les contrôles contre un appel frauduleuxComprendre pourquoi
  2. Falsification44 %des applications Android repèrent une copie reconditionnéeComprendre pourquoi
  3. Clés d’accès5 %des applications proposent les clés d’accèsComprendre pourquoi
  4. Plateformes partagées14 %des banques partagent une plateforme d’application toute faiteComprendre pourquoi
  5. Assistants IA30 %des applications avec un assistant IA ont une clé secrète dans leur code19,9 % pour les applications sans assistantComprendre pourquoi
  6. Bibliothèques3 versionsde retard sur la dernière version, pour les bibliothèques d'une application Android typeComprendre pourquoi
  7. Étiquettes de confidentialité64 %des étiquettes de confidentialité Android omettent des données accessibles à l’applicationComprendre pourquoi
  8. Clés secrètes18 %des applications Android embarquent une clé secrèteComprendre pourquoi

Plus de 3,7 milliards de téléchargements Google Play pour les applications analysées.

Les notes ignorent la sécurité : 3,8 étoiles avec une faille critique, 3,9 sans.

Protection du client

Connexion, paiements et arnaques, dans le code

Ce que les applications bancaires embarquent pour protéger leurs clients : contrôles autour des paiements et des arnaques, liaison du compte au téléphone et jusqu'où chaque application va, étape par étape.

Les protections de paiement et anti-arnaque que portent les applications

Une ligne par protection dans le code. Les points pleins sont les applications qui l'ont.

FIG. 1.1

Seules 19 % des applications bancaires ont du code de détection de fraude, et 17 % une alerte aux arnaques

  • Dans le code
  • Non trouvée
  • Un point = 2 % des applications

Applications Android, iOS et HarmonyOS, lues dans leur code. Les contrôles de superposition d’écran n’existent que sur Android et HarmonyOS : cette ligne est une part de ces applications.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Comment les applications connectent le client et le lient à son téléphone

Un mot de passe volé ne doit pas servir ailleurs. Points pleins : les applications qui le vérifient.

FIG. 1.2

90 % des applications lient le compte à un seul téléphone, mais seules 51 % gardent la clé dans la puce sécurisée

  • Dans le code
  • Non trouvé
  • Un point = 2 % des applications

Applications Android, iOS et HarmonyOS, lues dans leur code. Les requêtes signées, le contrôle du verrouillage d’écran et l’attestation de clé n’existent que sur Android et HarmonyOS : ces lignes sont des parts de ces applications.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

72 % des applications iOS se déverrouillent avec une simple vérification oui/non de l'empreinte ou du visage, qu'une application trafiquée peut simuler.

Jusqu’où vont les applications, étape par étape

Chaque étape ne compte que les applications qui ont aussi toutes les étapes précédentes : la part baisse au fil du parcours. Chaque téléphone représente 5 % des applications.

FIG. 1.3

Seules 11 % des applications bancaires ont toutes les étapes contre un appel frauduleux

Un fraudeur appelle et guide le client dans un paiement tout en regardant son écran. L’application peut-elle détecter l’appel, voir que l’écran est partagé, et avertir ?

100 % des applications ont encore toutes les étapes

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Résistance à la falsification

L’application le remarquerait-elle ?

Applications copiées, téléphones débridés, faux téléphones, outils de falsification : nous avons lu le code de chaque application Android pour trouver les contrôles qu'un attaquant rencontre. Faites d'abord une estimation.

FIG. 2.1

Applications dotées de chaque contrôle anti-falsification, sur 100

Sur 100 applications bancaires, combien ont ces neuf contrôles ?

Applications Android. Un contrôle compte seulement si le code propre de la banque l'utilise, pas s'il se trouve juste dans une bibliothèque externe.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

99 % de ces applications s'installent encore sur des versions d'Android qui ne reçoivent plus de correctifs de sécurité. C'est aussi le cas de 99 % de celles qui détectent les téléphones débridés : elles refusent un téléphone trafiqué mais acceptent un téléphone obsolète.

Défenses modernes

Les défenses qui rendent un mot de passe volé inutile

Avec un mot de passe volé, il existe quatre façons d'entrer dans un compte. Ces quatre défenses les ferment. Voici à quelle fréquence chacune figure dans le code des applications.

FIG. 3.1

Les clés d’accès bloquent deux types d’attaque, mais seules 5 % des applications les proposent

Défense Mot de passe hameçonné Téléphone d’un tiers Application modifiée Robots sur faux téléphonesDans le code
Clés d'accès5 %Dans le code
Contrôle d'application de Google, Play Integrity (Android)16 %Dans le code
Contrôle d'application d'Apple, App Attest ou DeviceCheck (iOS)21 %Dans le code
Empreinte ou visage qui déverrouille une clé sécurisée45 %Dans le code

Trouvé dans le code de l'application. Android : clés d'accès, vérification d'application de Google (Play Integrity) et clés verrouillées par empreinte. iOS : clés d'accès et vérifications d'application d'Apple. 4 % utilisent encore SafetyNet, le contrôle d'application que Google a arrêté.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

À quel point l’application est difficile à décortiquer

Avant de falsifier une application, un attaquant lit son code. Un code brouillé et un code natif renforcé le ralentissent. Une application conçue pour une ancienne version d'Android se prive de protections que les versions récentes activent par défaut.

FIG. 3.2

30 % des applications brouillent la majeure partie de leur code

  • 30 %des applications brouillent la majeure partie de leur code (obfuscation)
  • 67 %des applications ayant leur propre code natif le compilent avec toutes les protections standard (PIE, stack canaries, RELRO)
  • 72 %des applications Android sont conçues pour une version actuelle d'Android

Applications Android dont nous avons pu lire le code. Code masqué : compté seulement pour les applications écrites en Java ou Kotlin. Code natif : applications avec leur propre code de bas niveau. À jour : Android 16 ou plus récent.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Des clés d’accès dans l’application, mais pas sur le site de la banque

Une clé d’accès a besoin de deux moitiés : du code dans l’application, et un fichier sur le site de la banque qui nomme l’application. Sans ce fichier, le téléphone ne propose pas de clé d’accès pour la banque. Nous avons vérifié les deux moitiés dans chaque application Android et iOS. Le téléphone montre d'abord comment fonctionne une clé d'accès, puis tente de se connecter sur chaque application prévue pour les clés d'accès.

FIG. 3.3

Seules 10 % des applications Android prévues pour les clés d’accès peuvent vraiment s’en servir

Étape 1 sur 3

Une clé d'accès remplace le mot de passe

Vous vous connectez avec votre empreinte ou votre visage. Rien à taper, donc rien à voler ni à hameçonner.

Site prêt : le site de la banque indique l'application pour la connexion par clé d'accès. Les applications sans aucune des deux moitiés ne sont pas montrées. Sur iOS, nous ne comptons que le code de clé d'accès confirmé. Les applications HarmonyOS sont exclues : elles ne gèrent pas les clés d'accès.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Plateformes partagées

Un fournisseur, de nombreuses banques

Quelques plateformes d'applications toutes faites et bibliothèques de code se retrouvent dans de nombreuses applications bancaires. Une seule faille dans l'une d'elles touche beaucoup de banques à la fois.

FIG. 4.1

Une seule faille dans la plus grande plateforme partagée toucherait 4 banques sur 100

14banques sur 100 construisent leur application sur une plateforme partagée

  • Backbase 4 %
  • Q2 3 %
  • Oracle FLEXCUBE 3 %
  • NCR D3 2 %
  • Temenos 2 %
  • Aucune plateforme partagée trouvée 86 %

Également partagés dans les applications, quel qu'en soit le concepteur

Bibliothèques de code tierces

  1. Firebase Analytics56
  2. Firebase Crashlytics48
  3. Huawei Mobile Services13
  4. Dynatrace12
  5. AppsFlyer11

Produits de protection d'application

  1. Google Play integrity protection14
  2. IBM Trusteer3
  3. Zimperium2

385 banques vérifiées · Applications Android dont nous avons pu lire le code. Une banque compte pour une plateforme quand l’une de ses applications est construite dessus ; une banque sur deux plateformes ne compte qu’une fois. Une banque de plus utilise TCS BaNCS (moins de 1 %). Bibliothèques et produits de protection : part des applications. Huawei Mobile Services est haut placé car beaucoup d’applications Google Play l’embarquent aussi, pour fonctionner sur les téléphones Huawei.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Un produit de protection ne rend pas une application saine : celles qui en ont un ont plus souvent une clé secrète dans le code (29 % contre 19 %) et une vieille bibliothèque avec une faille connue (53 % contre 40 %).

Applications clés en main

Même plateforme, mêmes protections

Certaines banques achètent une application clés en main (en marque blanche) à un éditeur. Nous avons comparé chaque paire d’applications d’un même éditeur, sur leurs faiblesses et leurs protections, puis fait de même pour des applications sans lien. Elles partagent nettement leurs protections ; pour les faiblesses, c’est plus mitigé, et chez certains éditeurs elles en partagent moins que des applications sans lien. Chaque feuille est l’application d’une banque, et son cercle contient ses faiblesses ou ses protections. Le chevauchement est ce que les deux partagent. L’anneau en pointillé montre le chevauchement pour deux applications sans lien.

FIG. 4.2

Deux applications Temenos partagent 67 % de leurs protections ; deux applications sans lien, 25 %

Les applications de deux banques, toutes deux construites sur Q2

Bâtie sur Q2 petit groupe

62 %en commun

2,5× des applications sans lien

Q262 %
Applications sans lien25 %

16 applications

En commun : de toutes les failles (ou protections) de deux applications, la part qu'elles partagent, valeur type sur chaque paire d'applications d'un éditeur. Applications sans lien : 20 000 paires au hasard. Q2 et NCR D3 sont de petits groupes. Nous repérons les éditeurs dans le code : les applications sans leurs marques sont manquées.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Ce que font les applications

Ce que les applications bancaires savent faire en 2026

Virements entre particuliers, contrôle des cartes, cartes virtuelles, budgets : nous avons compté les fonctions que chaque application a dans son code et décrit sur sa page de store. Chacune est accessible à un attaquant.

FIG. 5.1

3 des 4 fonctionnalités bancaires sont plus courantes dans les applications des néobanques que dans celles des banques traditionnelles

  • Banques traditionnelles
  • Néobanques
  1. Virements entre particuliers16 %28 %
  2. Blocage et contrôle de la carte27 %24 %
  3. Cartes virtuelles et à usage unique5 %28 %
  4. Budgets et analyse des dépenses13 %48 %

Compté seulement quand le code de l'application contient la fonctionnalité et que sa page de store la mentionne. Applications Android et iOS. Néobanques : 29 applications, un petit groupe ; banques traditionnelles : 848 applications.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

À quoi ressemble le téléchargement lui-même

Avant toute fonction, il y a le téléchargement : ce qu'il demande, sa taille, la fréquence de ses mises à jour et l'âge des téléphones sur lesquels il tourne encore.

FIG. 5.2

L’application bancaire Android type demande 23 permissions et pèse 68 Mo

  • 23autorisations demandées par l'application type
  • 68Mo, le téléchargement type
  • 9versions par an, pour l’application Android type
  • 99 %des applications Android s'installent encore sur un système de téléphone qui n'est plus mis à jour

Applications Android. « Type » désigne la valeur médiane. Ancien système : l’application s’installe encore sur Android 13 ou plus ancien, qui ne reçoit plus de correctifs de sécurité.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Mettre à jour souvent ne veut pas dire moins de failles : 63 % des applications Android mises à jour au moins toutes les trois semaines ont une faille critique ou élevée, contre 51 % de celles mises à jour moins d'une fois tous les trois mois. Les dates viennent des versions citées dans les avis des stores.

Assistants IA

Les assistants IA ouvrent de nouvelles portes

Les banques ajoutent des assistants IA à leurs applications. Chacun est un nouvel endroit où oublier une clé.

3,7 %

des applications bancaires intègrent un assistant IA

30 % d'entre elles ont une clé secrète écrite dans l'application, que n'importe qui peut récupérer.

FIG. 6.1

30 % des applications avec un assistant IA laissent une clé secrète dans leur code, contre 19,9 % sans assistant

Voyez l'application comme une porte d'entrée : une clé laissée dans le code est une clé laissée sur le seuil. Regardez ce qui se passe quand la banque ajoute un assistant IA.

Clé sous le paillassonOnt une clé secrète dans le codeSans assistant19,9 %Avec un assistant IA30 %1,5× plus fréquent dès qu’il y a un assistant IA

Les applications sans assistant laissent aussi des secrets, mais moins souvent : une sur cinq.

Assistant : un chatbot intégré à l’application ; le chat en direct avec une personne ne compte pas. Clé secrète : une clé dont notre scan est sûr, hors clés d’API Google, que les applications embarquent par conception. Aucune application n’avait de clé pour un service d’IA. 2 applications appellent Gemini, l’IA de Google, et aucune des deux n’a d’assistant. Les grandes banques ont plus souvent à la fois un assistant et davantage de modules : c’est un lien, pas une cause.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Mises à jour et confidentialité

À quel point les bibliothèques des applications sont dépassées

Les applications sont construites à partir de bibliothèques de code toutes faites, et la plupart ont des versions plus récentes. Pour chaque bibliothèque, nous avons compté de combien de versions elle est en retard. Faites glisser le curseur.

3

versions de retard, pour les bibliothèques de l’application type

FIG. 7.1

98 % des applications bancaires Android ont au moins une bibliothèque en retard de 10 versions

99 %des applications ont des bibliothèques en retard, en général, de 1 version ou plus.

Applications Android. Chaque bibliothèque est comparée à sa dernière version stable.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Pas seulement les bibliothèques : environ 1 banque sur 20 a déjà eu une faille de sécurité publique (CVE) dans sa propre application, le plus souvent il y a des années.

Étiquettes des stores et réalité des applications

64 %

des applications bancaires Android omettent de leur étiquette de confidentialité une donnée que l’application demande ou qu’un code partenaire collecte

Part des applications dont l’étiquette omet cette donnée, alors que l’application la demande ou embarque un code partenaire qui la collecte.

Android ou iOS

Une banque, deux applications, deux niveaux de sécurité

La plupart des banques ont une application Android et une application iOS. Même nom, même logo, mais souvent conçues par des équipes différentes. Nous avons passé les mêmes contrôles sur les deux applications de chaque banque qui en a deux.

80 %

des banques ont au moins une vérification sur laquelle leurs deux applications divergent

La protection d’un client dépend du téléphone qu’il utilise, et un attaquant n’a besoin que de l’application la plus faible.

FIG. 8.1

Les applications Android font moins bien que celles d’iOS sur 3 contrôles sur 3

Contrôles où les applications de cette plateforme font moins bien

Les banques dont nous avons pu lire en entier le code Android et iOS, un groupe plus petit que celui de la fig. 8.3, dont les deux applications ont été scannées. Chaque ligne est un problème : plus c'est à droite, pire c'est.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Banque par banque

Même banque, même vérification, réponse différente

Un cercle regroupe les banques dont l’application Android a le problème, l’autre celles dont l’application iOS l’a. Dans le chevauchement, les deux l’ont. Les points hors du chevauchement sont des banques dont les applications diffèrent : corriger l’une laisse l’autre ouverte.

FIG. 8.2

Chez 80 % des banques, les applications Android et iOS diffèrent sur au moins un contrôle

32 banques sur 100 : le problème est dans une application et pas dans l’autre

  • 19 Android seul
  • 16 Les deux
  • 13 iOS seul
  • 52 Aucune

Chaque barre représente 100 banques : Android seul, les deux applications, iOS seul, puis aucune. Le chiffre indique les banques dont les deux applications divergent.

Présenté sur 100 banques, à partir des 75 qui ont les deux applications. La taille des cercles est à l’échelle ; un point par banque.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Applications jumelles

Même banque, deux applications : laquelle tient le mieux ?

Pour 152 banques, nous avons analysé à la fois l'application Android et l'application iOS, puis comparé les deux versions de chaque banque. Les deux téléphones tombent ensemble. Pour les protections et le score, chaque case est une banque, au même endroit sur les deux écrans, allumée du côté de son application la plus solide. Pour les failles critiques, chaque case rouge est une application avec une faille grave, comptée sur chaque plateforme.

FIG. 8.3

54 % des applications Android des banques ont une faille grave, contre 34 % de leurs applications iOS

Android54 %

iOS34 %

Chaque case rouge est une application avec une faille critique ou élevée, comptée sur chaque plateforme, sans appariement banque par banque.

Les 152 banques dont les deux applications ont été analysées. Protections : les 9 contrôles anti-falsification communs aux deux plateformes. Les règles d'analyse diffèrent selon la plateforme : la comparaison des scores n'est qu'indicative.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Hors de l’application

Ce que les attaquants trouvent sans ouvrir l’application

Fausses applications dans les stores, adresses web similaires, e-mails que n’importe qui peut usurper, anciennes configurations de serveurs : un attaquant peut cartographier une banque à partir de sources publiques avant même de toucher à son application. Nous avons regardé ce que chacune laisse à découvert.

FIG. 9.1

97 % des banques ont des adresses web similaires enregistrées, par des tiers ou par la banque elle-même

28 %

des banques ont des applications d’autres éditeurs portant leur nom dans les magasins d’applications

Des applications sur Google Play, l’App Store ou AppGallery qui utilisent le nom de la banque mais viennent de quelqu’un d’autre (partenaires de la banque exclus). À examiner : toutes ne sont pas des contrefaçons.

486 banques vérifiées · Sources publiques et sites publics des banques. 500 banques, 1 252 sites bancaires.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Une banque, des dizaines de sosies

Une banque type compte 28 adresses web enregistrées à une petite modification de la sienne. Voici comment elles sont fabriquées, sur une banque inventée.

FIG. 9.2

54 % des adresses similaires sont construites de la même façon : une lettre manquante ou doublée

La vraie adressemabanque.com

486 banques vérifiées · yourbank.com est inventé, pour montrer le principe. Les parts portent sur 4 132 adresses imitées, regroupées selon leur différence avec la vraie.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Serveurs

Où se trouvent les backends

Toute application bancaire échange avec des serveurs : ils connectent les clients, déplacent l'argent et envoient les alertes. Nous avons relié les serveurs propres à chaque banque, trouvés dans ses applications, aux réseaux qui les font tourner. La plupart sont sur un réseau cloud mondial (comme AWS ou Cloudflare), qui peut être n'importe où ; les autres sur les réseaux propres des banques, surtout dans leur pays.

FIG. 10.1

60 % des serveurs bancaires sont derrière un grand réseau cloud mondial

Chaque ligne va de la région vers un pays où se trouvent les serveurs propres de ses banques. Plus la ligne est épaisse, plus la part est grande.

84 %

des serveurs des banques de Amérique du Nord sont sur un réseau cloud mondial, qui peut répondre de partout

Parmi les hôtes sur leurs propres réseaux, 10 % sont hors de la région Amérique du Nord.

Hôtes sur les réseaux propres des banques, par pays

  1. États-Unis90 %
  2. Pays-Bas8 %
  3. France1 %
  4. Autres pays1 %

392 banques vérifiées · Où se trouvent les serveurs des banques, d’après leurs applications Android, iOS et HarmonyOS. Les clouds mondiaux peuvent répondre de partout : les pays ne sont indiqués que pour les serveurs sur les propres réseaux des banques.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Quand un fournisseur tombe en panne

La plupart de ces serveurs tournent chez une poignée de fournisseurs cloud. Choisissez-en un et coupez-le : chaque téléphone est l'application d'une banque, sur 100, et montre ce que ses clients perdraient.

FIG. 10.2

Si AWS tombait en panne, 41 banques sur 100 perdraient une partie de leur application

  • 0 banques perdent toute l'application : tous leurs serveurs sont chez ce fournisseur
  • 0 banques perdent une partie de l’application : certains backends y reposent
  • 100 banques continuent de fonctionner : aucun serveur chez lui

Toutes les applications fonctionnent. Choisissez un fournisseur pour le mettre hors service.

392 banques vérifiées · Quelle entreprise gère chaque serveur bancaire cité dans les applications des banques. 392 banques ont au moins un tel serveur.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

64 % des banques placent au moins un serveur derrière un fournisseur qui vend un filtre contre les attaques web, ou WAF (Akamai, Imperva, Cloudflare ou F5).

Quand la banque cesse de fonctionner

Les banques de détail britanniques doivent signaler chaque incident majeur qui interrompt un service ou le met en danger. Année après année, la plupart sont des pannes informatiques, pas des attaques, et beaucoup commencent par un changement raté ou chez un fournisseur.

FIG. 10.3

Les banques de détail britanniques ont signalé 3 271 incidents majeurs depuis 2018 ; seuls 147 étaient des cyberattaques

Leur origine, sur l’ensemble des incidents

Tout le secteur bancaire, aucune banque nommée. « Tiers » et « changement » indiquent l'origine d'un incident. *2026 jusqu'au 9 juillet, provisoire.

Source : Financial Conduct Authority (Royaume-Uni), incidents opérationnels majeurs déclarés par les banques de détail (FOI2026/01239)

Rapports publics et régulateurs ont recensé des pannes bancaires dans 33 pays depuis 2025 ; la plus longue a privé une banque de son application mobile pendant environ 48 heures.

Dans le viseur des attaquants

Déjà dans le viseur des attaquants

Les chevaux de Troie bancaires sont des logiciels malveillants qui volent les identifiants. Chacun porte une liste des applications qu’il sait imiter : quand l’une d’elles s’ouvre, il affiche un faux écran de connexion par-dessus. Des chercheurs en sécurité publient ces listes, et nous les avons croisées avec les banques de ce rapport.

FIG. 11.1

Le cheval de Troie bancaire le plus répandu cible les applications de 35 banques sur 100

50 banques sur 100 figurent sur la liste de cibles d’au moins un cheval de Troie. 34 sur trois listes ou plus.

Un badge rouge indique combien de familles de chevaux de Troie ciblent l’application de cette banque. Touchez une application pour l’ouvrir.

389 banques vérifiées · 47 listes d’applications ciblées par des malwares bancaires, publiées par des chercheurs en sécurité de 2019 à 2025, rapprochées des applications Android des banques. Figurer sur une liste signifie être ciblé, pas infecté. Chaque téléphone est une banque anonyme : 100 banques choisies pour que les parts correspondent aux 389.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Seules 2 campagnes d’attaque cette année ont utilisé des copies modifiées de vraies applications bancaires (GoldFactory et Hirudo). Les autres ont utilisé de fausses applications ressemblantes, ou de faux écrans affichés sur la vraie application.

Dossiers

Quatre attaques de 2026, dossier par dossier

Des chercheurs en sécurité ont décrit ces attaques contre des clients bancaires cette année. Chaque dossier déroule une attaque, puis la compare à ce que nous avons trouvé dans les applications. Ni les sources ni nous ne nommons de banque.

Cheval de Troie bancaire Android

Le cheval de Troie qui remplace votre application bancaire

Hirudo va plus loin que de faux écrans par-dessus l’application de la banque. Il supprime la vraie application et installe une copie trafiquée qui trompe ses propres contrôles de sécurité.

Source: ThreatFabric, octobre 2026
  • 42applications financières sur sa liste de cibles
  • 8applications bancaires avec une copie trafiquée prête, de 7 banques
  • 1 lignede code ajoutée à chaque copie pour charger l’outil qui la détourne

Comment ça marche

Ce que montrent nos données

  • 44 %des applications bancaires Android vérifient si elles ont été reconstruites et re-signées
  • 45 %se protègent dans leur propre code des faux écrans superposés ou de l’abus de l’Accessibilité
  • 56 %bloquent les captures d’écran
  • 16 %utilisent le contrôle Play Integrity de Google

D'après le code des applications (fig. 2.1 et 3.1). Quand un logiciel malveillant remplace l'application, la meilleure défense est un contrôle sur le serveur de la banque.

Ce qui l’arrête

  • Vérifier le verdict Play Integrity de Google sur le serveur, pour chaque session et action sensible.
  • Vérifier les certificats de clé du téléphone avec la liste des clés révoquées de Google.
  • Garder des contrôles anti-fraude sur le serveur à la connexion, à la récupération du compte, pour les nouveaux bénéficiaires et les paiements.
  • Utiliser les signes d’Accessibilité et de capture d’écran comme signaux de risque, pas comme seul blocage.

Le coût de la fraude

Ce que coûte la fraude, et qui la paie

Les failles des applications sont un côté de l’histoire ; l’argent perdu est l’autre. Ces chiffres viennent des tableaux publiés par les régulateurs, pas de nos tests. Ils décrivent le marché, pas une banque que nous avons analysée.

FIG. 12.1

Dans l’UE, les clients ont supporté eux-mêmes 66 € sur 100 € perdus à cause de la fraude aux paiements

Sur l’ensemble de la fraude aux paiements dans l’UE, les clients ont supporté eux-mêmes 66 € sur 100 €.

  • 66 €Le client
  • 22 €La banque du client ou l’émetteur de la carte
  • 12 €Autres, comme les commerçants
  • 2 155 €perdus en moyenne par virement frauduleux
  • 20 €de fraude pour chaque million d’euros payé, tous types de paiement
  • 150paiements par carte frauduleux par million

UE : rapport 2025 des autorités bancaires européennes sur la fraude, données 2024, pertes après recouvrement, selon qui a payé. Royaume-Uni : régulateur des paiements, remboursements des escroqueries où le client a été piégé, du 7 octobre 2024 au 31 mars 2026. Le coût est partagé à parts égales entre la banque émettrice et la banque destinataire.

Source : ABE et BCE, rapport sur la fraude aux paiements (2025) ; Payment Systems Regulator (Royaume-Uni)

Une validation forte réduit la fraude ; envoyer de l’argent à l’étranger l’augmente

La fraude à la carte, selon la façon dont le paiement a été validé et l’endroit où l’argent est allé.

FIG. 12.2

Les paiements par carte sans vérification forte de l’identité ont subi 1,9× plus de fraude

Chaque tuyau achemine le même million d’euros de paiements, des clients vers les personnes et commerces qu’ils paient. L’or qui fuit en chemin correspond à ce que la fraude a pris, recueilli dans le verre en dessous.

Les clients versent 1 million d’euros dans chaque tuyau

Paiements par carte en 2024. Source : rapport 2025 de l’ABE et de la BCE sur la fraude.

Source : ABE et BCE, rapport sur la fraude aux paiements

Où atterrit l’argent des escroqueries

Au Royaume-Uni, le régulateur publie, pour chaque établissement, l’argent d’arnaque envoyé par ses clients et celui qui arrive sur ses comptes. Un établissement bien au-dessus de la ligne reçoit bien plus qu’il n’envoie : des escrocs utilisent ses comptes pour encaisser.

FIG. 12.3

3 des 11 plus grands établissements britanniques reçoivent plus d’argent escroqué que leurs clients n’en envoient

3 établissements sur 11 reçoivent plus d’argent escroqué que leurs clients n’en envoient

Régulateur britannique des paiements, données 2024 sur les escroqueries, avant les règles de remboursement du 7 octobre 2024. 11 des 14 plus grands groupes bancaires, ceux qui envoient et reçoivent. Les établissements ne sont pas nommés.

Source : régulateur britannique des paiements, données sur les paiements frauduleux

Après la réclamation

FIG. 12.4

88 % des sommes déclarées perdues dans des escroqueries ont été remboursées

Délai de décision82 % en 5 jours ouvrés au plus98 % en 35 jours ouvrés au plus

88 % des sommes déclarées perdues ont été remboursées

  • 12 % de l’argent n’est jamais revenu : le trou dans le cochon
  • 88 % sont revenus : l’or qui répare la tirelire

Régulateur britannique des paiements : demandes de remboursement pour escroquerie du 7 octobre 2024 au 31 mars 2026. Part de l'argent réclamé remboursée ; on ne sait pas combien de demandes ont été remboursées en totalité, en partie ou pas du tout.

Source : régulateur britannique des paiements, données sur les paiements frauduleux

C’est dans la fraude que la sécurité des applications se traduit en argent. Les protections du chapitre 1 sont la part de ce problème qu’une banque maîtrise.

Réglementation et maturité

Réglementation, taille et image publique des banques

Les banques ont des régulateurs différents, des tailles très différentes et des façons différentes de traiter avec les chercheurs en sécurité. Nous avons comparé chacun de ces points avec ce que nous avons trouvé dans leurs applications.

FIG. 13.1

Sécurité des applications par régulateur, et pour les plus grandes banques

Inde (RBI) compte le moins d’applications avec une vulnérabilité critique : 8 %, contre 18 % pour l’ensemble des banques.

444 banques vérifiées · Les banques sont regroupées selon le régulateur de leur pays ; les plus grandes banques du monde forment aussi leur propre groupe. Failles critiques et clés d'accès : part des applications. Contrôles anti-falsification : part des contrôles de la fig. 2.1 qu'a une application type.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Les banques qui semblent matures font-elles mieux ?

Certains signes qu’une banque prend la sécurité au sérieux sont publics : un fichier security.txt qui dit aux chercheurs où signaler, une politique de divulgation, un bug bounty qui rémunère les failles signalées, une certification sur son site. Choisissez-en un pour couper les banques en deux et comparer leurs applications.

FIG. 13.2

Banques avec une vulnérabilité critique, avec ou sans chaque signal

21 points de banques en moins avec une vulnérabilité critique quand elles ont un fichier security.txt.

Avec un fichier security.txt30 %
Sans51 %

444 banques vérifiées · Les 444 banques avec une application analysée. Chaque signe vient de sources publiques : le site de la banque, son fichier de contact sécurité, les programmes publics de bug bounty et les certifications qu'elle revendique.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

10 % des banques ont eu une fuite de données rendue publique ces cinq dernières années, d’après des bases de fuites, des sites de rançongiciels et des déclarations aux régulateurs.

D’une année sur l’autre

Qui progresse, et sur quoi

Toutes les applications testées chaque année. Plus bas, c'est mieux, sur chaque ligne.

FIG. 14.1

3 des 4 indicateurs se sont améliorés entre 2025 et 2026

  • 2025
  • 2026

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Le plus grand nombre de failles graves dans une seule application : 19 en 2025, 18 en 2026.

Nouveautés de cette année

Des vérifications que nous publions pour la première fois. Le rapport 2025 ne donnait pas de part pour elles : il n’y a donc pas encore de point de comparaison.

FIG. 14.2

59 % des applications stockent des données sensibles sans protection sur le téléphone

  • 51 %utilisent un chiffrement faible (MD5 ou mode ECB, par exemple)
  • 59 %stockent des données sensibles sans protection sur le téléphone
  • 35 %affichent des pages web dans un navigateur intégré non sécurisé
  • 16 %ouvrent des liens vers l'application sans les vérifier
  • 11 %laissent sauvegarder leurs données hors du téléphone (sauvegardes autorisées)
  • 7 %demandent une permission dangereuse dont elles ne semblent pas avoir besoin
  • 3 %construisent des requêtes de base de données à partir de données externes (injection SQL)
  • 1 %peuvent être piégées par un faux écran par-dessus (tapjacking)

Applications Android, analyse Ostorlab : applications avec au moins une faille de ce type, de risque faible ou plus.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Hier et aujourd’hui : les mesures déjà publiées en 2025

Les mêmes mesures que le rapport 2025, un an plus tard. La plupart décrivent les applications plutôt que des failles : lisez-les comme une évolution, pas comme un mieux ou un moins bien.

FIG. 14.3

Les mêmes mesures, de 2025 à 2026

Les chiffres 2025 viennent du rapport 2025.

Source : analyse Ostorlab de 2 690 applications bancaires de 500 banques, 2026

Méthode

Comment nous avons testé

Deux sources. Les applications elles-mêmes, lues et scannées par Ostorlab : quatre des cinq cartes ci-dessous. Et les informations publiques, la troisième carte : pages des stores, sites des banques, rapports de menaces et tableaux des régulateurs.

  1. Lecture du code

    De quoi chaque application est faite : frameworks, code tiers, permissions, serveurs, défenses. Toutes les applications.

  2. Analyse

    Problèmes trouvés, classés par risque, rattachés au standard mobile OWASP. Toutes les applications.

  3. 500 banques

    Données publiques

    Pages des stores, classements, certificats, rapports de menaces et sites publics des banques. Toutes les banques.

  4. Contrôles de protection

    Contrôles dans le code contre les téléphones déverrouillés, les faux téléphones, les outils de falsification et les copies reconstruites. Android.

  5. Protections des clients

    Protections de connexion, de paiement et anti-arnaque trouvées dans le code. Toutes les applications.

Périmètre. Uniquement les versions publiques des applications dans les stores, lues sans les exécuter.

Nous avons analysé des applications bancaires sur Android, iOS et HarmonyOS (Huawei AppGallery).

Pages des stores lues du 28 octobre au 9 novembre 2026.

Termes utilisés dans ce rapport
API
Interface qui permet à un programme de demander des données ou des actions à un autre.
SDK
Bloc de code prêt à l’emploi inclus dans une application, souvent d’une autre entreprise.
SMS
Messages texte, utilisés ici pour les codes de connexion à usage unique.
OWASP
Organisation à but non lucratif qui publie des guides de sécurité applicative très utilisés.
MASVS
Liste d’exigences de sécurité de l’OWASP pour les applications mobiles.
PIE
Option de compilation qui charge le code à un endroit aléatoire de la mémoire, pour compliquer les attaques.
RELRO
Option de compilation qui rend une partie de la mémoire de l’application en lecture seule au démarrage.
MD5
Ancienne méthode d’empreinte de données, plus sûre pour la sécurité.
ECB
En chiffrement, un mode qui laisse voir des motifs, peu sûr. Aussi la Banque centrale européenne, au chapitre fraude.
OAuth
Norme pour se connecter à un service avec le compte d’un autre.
CVE
Identifiant public d’une faille de sécurité connue.
HSTS
Réglage d’un site qui impose aux navigateurs les connexions sécurisées (HTTPS).
DMARC
Règle e-mail qui demande aux autres serveurs de rejeter les messages usurpant l’adresse de la banque.
WAF
Pare-feu applicatif web : filtre qui bloque les attaques avant qu’elles atteignent un serveur.
PSD2
Directive européenne sur les services de paiement, qui impose une authentification forte.
DORA
Règlement européen sur la résilience numérique des acteurs financiers.
EBA
Autorité bancaire européenne, le régulateur bancaire de l’UE.
FFIEC
Conseil américain qui fixe des normes d’inspection communes aux régulateurs bancaires.
PRA
Prudential Regulation Authority, un régulateur bancaire britannique.
FCA
Financial Conduct Authority, le régulateur britannique des pratiques financières.
GCC
Conseil de coopération du Golfe : Arabie saoudite, Émirats, Qatar, Koweït, Bahreïn et Oman.
RBI
Reserve Bank of India, banque centrale et régulateur bancaire indien.
PBOC
Banque populaire de Chine, la banque centrale chinoise.
NFRA
Administration nationale de régulation financière, le régulateur bancaire chinois.
G-SIB
Banque d’importance systémique mondiale : l’une des plus grandes banques du monde, listées par le Conseil de stabilité financière.

Toutes les éditions

Télécharger le rapport complet

54 pages : tous les graphiques, les études de cas, les résultats par région et notre méthode.

Télécharger le rapportÉchanger avec l’équipe à l’origine du rapport