2026 版

移动银行应用安全2026

独立数字银行的应用被评为高风险的比例高于传统银行的应用:79% 对 51%。

  • 未被评为高风险
  • 被评为高危或严重
  • 10 家独立数字银行的 29 个应用,对比我们扫描的所有其他银行应用。

移动银行应用安全

深入 2,690 款银行应用

我们研究了来自 500 家银行、覆盖 Android、iOS 和 HarmonyOS 的 2,690 款银行应用。数据来源有两个:由 Ostorlab 读取和扫描的应用本身,以及应用商店页面、银行网站和威胁报告等公开信息。

2026 移动银行应用安全报告封面

关键发现

关键发现一览

  1. 诈骗电话11%的应用具备防范诈骗电话的全部检查了解原因
  2. 篡改44%的 Android 应用能察觉重新打包的副本了解原因
  3. 通行密钥5%的应用提供通行密钥了解原因
  4. 共享平台14%的银行共用现成的应用平台了解原因
  5. AI 助手30%带 AI 助手的应用在代码中含有密钥未配备助手的应用为 19.9%了解原因
  6. 依赖库3 个版本典型 Android 应用的库落后于最新版本了解原因
  7. 隐私标签64%的 Android 应用隐私标签未列出应用可访问的数据了解原因
  8. 密钥18%的 Android 应用内置了密钥了解原因

我们检查的 Android 应用在 Google Play 累计下载超过 37 亿次。

评分不反映安全性:有严重漏洞的应用 3.8 星,其余 3.9 星。

客户保护

代码中的登录、支付与防诈骗

银行应用为保护客户所具备的能力:围绕支付和诈骗的检测、账户与手机的绑定方式,以及每个应用逐步能做到哪一步。

应用携带了哪些支付与防诈骗保护

每行是代码中的一项防护。实心点是具备该防护的应用。

图 1.1

只有 19% 的银行应用有反欺诈检测代码,有诈骗警告的仅 17%

  • 代码中有
  • 未发现
  • 一个点 = 2% 的应用

Android、iOS 与 HarmonyOS 应用,读取自其代码。屏幕覆盖检查仅适用于 Android 和 HarmonyOS,因此该行是这些应用中的占比。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

应用如何登录客户并将其与手机绑定

被盗的密码不应在另一部手机上可用。实心点是会检查这一点的应用。

图 1.2

90% 的应用把账户绑定到一部手机,但只有 51% 把密钥存放在手机的安全芯片中

  • 代码中有
  • 未发现
  • 一个点 = 2% 的应用

Android、iOS 与 HarmonyOS 应用,读取自其代码。请求签名、锁屏检查和密钥证明仅存在于 Android 和 HarmonyOS,因此这些行是这些应用中的占比。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

72% 的 iOS 应用仅凭简单的指纹或面容“是/否”检查解锁,被篡改的应用可以伪造这一结果。

应用一步步能做到哪一步

每一步只统计也具备之前所有步骤的应用,因此比例会逐步下降。每部手机代表 5% 的应用。

图 1.3

仅 11% 的银行应用具备应对诈骗电话的所有步骤

诈骗者打来电话,一边看着客户的屏幕一边引导其付款。应用能否识别通话、发现屏幕正在共享并发出警告?

100% 的应用仍具备所有步骤

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

抗篡改能力

应用会察觉吗?

被复制的应用、解锁的手机、假手机、篡改工具:我们读取了每个 Android 应用的代码,查找攻击者会遇到的检测。先猜一猜。

图 2.1

具备各项防篡改检测的应用(每 100 个)

在 100 个银行应用中,有多少个具备全部九项检测?

Android 应用。只有银行自己的代码使用某项检测时才计入,仅存在于外部库中的不计入。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

其中 99% 的应用仍可安装在已不再获得安全修复的 Android 版本上。检测解锁手机的应用中也有 99% 如此:它们拒绝被篡改的手机,却放行过时的手机。

现代防御

让被盗密码失效的防御措施

拿着被盗的密码,有四条路可以进入账户。这四种防御能把它们堵上。下面是每种防御在应用代码中出现的频率。

图 3.1

通行密钥能挡住两类攻击,但只有 5% 的应用提供

防御措施 被钓鱼的密码 他人的手机 篡改的应用 假手机上的机器人在代码中
通行密钥5%在代码中
Google 的应用校验 Play Integrity(Android)16%在代码中
Apple 的应用校验 App Attest 或 DeviceCheck(iOS)21%在代码中
用指纹或面容解锁安全密钥45%在代码中

在应用代码中发现。Android:通行密钥、Google 的应用校验(Play Integrity)和指纹锁定的密钥。iOS:通行密钥和 Apple 的应用校验。 4% 仍在使用 Google 已停用的应用校验 SafetyNet。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

应用有多难被拆解

攻击者篡改应用前会先阅读其代码。混淆过的代码和加固的原生代码会拖慢他们。为旧版 Android 构建的应用,会错过新版本默认开启的防护。

图 3.2

30% 的应用对大部分代码做了混淆

  • 30%的应用对自身大部分代码做了混淆
  • 67%的自带原生代码的应用在构建时开启了全部标准防护(PIE、栈金丝雀、RELRO)
  • 72%的 Android 应用面向当前 Android 版本构建

我们能读取代码的 Android 应用。代码隐藏:仅统计用 Java 或 Kotlin 编写的应用。原生代码:带有自身底层代码的应用。最新:Android 16 或更新。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

应用里有通行密钥,银行网站却没配置

通行密钥需要两部分:应用里的代码,以及银行网站上一个指明该应用的文件。没有这个文件,手机就不会为该银行提供通行密钥。我们检查了每个 Android 和 iOS 应用的这两部分。 手机先演示通行密钥如何工作,然后在每个支持通行密钥的应用上尝试登录。

图 3.3

为通行密钥而开发的 Android 应用中,只有 10% 真正能用

第 1 步,共 3 步

通行密钥取代密码

用指纹或面容登录。无需输入任何内容,也就没有可被窃取或钓鱼的东西。

网站就绪:银行网站已将该应用登记用于通行密钥登录。两部分都没有的应用未显示。iOS 只统计我们能确认的通行密钥代码。HarmonyOS 应用不支持通行密钥,因此未纳入。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

共享平台

一家供应商,众多银行

少数现成的应用平台和代码库存在于许多银行应用中。其中一个出现漏洞,就会同时影响许多银行。

图 4.1

最大的共享应用平台只要有一个漏洞,就会波及每 100 家银行中的 4 家

14家(共 100 家)银行在共享平台上构建应用

  • Backbase 4%
  • Q2 3%
  • Oracle FLEXCUBE 3%
  • NCR D3 2%
  • Temenos 2%
  • 未发现共享平台 86%

无论由谁开发,应用内部同样共享的部分

第三方代码库

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

应用防护产品

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

已检查 385 家银行 · 我们能读取代码的 Android 应用。银行有应用基于某平台构建即计入该平台;横跨两个平台的银行只计一次。另有一家银行使用 TCS BaNCS(不到 1%)。库与保护产品:应用占比。Huawei Mobile Services 排名靠前,是因为许多 Google Play 应用也内置了它,以便在华为手机上运行。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

有防护产品并不代表应用就干净:使用防护产品的应用更常在代码中含有密钥(29% 对 19%),也更常带有已知漏洞的旧代码库(53% 对 40%)。

现成应用

同一平台,同样的保护

有些银行从供应商处购买现成的(白标)应用。我们把同一供应商的应用两两比较其弱点和保护措施,并对无关应用做了同样的比较。它们的保护措施明显相同;弱点则不一,有些供应商的应用共同弱点比无关应用还少。 每张图纸是一家银行的应用,圆圈里是它的弱点或防护。重叠部分是两个应用共有的。虚线圈表示两个无关应用的重叠程度。

图 4.2

两款 Temenos 应用有 67% 的保护措施相同;两款无关应用为 25%

两家银行的应用,均基于 Q2 构建

基于 Q2 构建 小组

62%相同

是无关应用的2.5倍

Q262%
无关应用25%

16个应用

Q2:共同部分62%,是无关应用的2.5倍

共同部分:两个应用所有漏洞(或防护)中双方都有的比例,取供应商所有应用两两配对的典型值。无关应用:随机抽取的 20,000 对。Q2 和 NCR D3 是小样本组。我们从代码中识别供应商,因此没有其标记的应用会被遗漏。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

应用功能

2026 年银行应用能做什么

个人转账、卡片管控、虚拟卡、预算:我们统计了每个应用代码中具备、并在商店页面中介绍的功能。每一项都是攻击者能触及的地方。

图 5.1

4 项银行功能中,有 3 项在数字银行应用中比在传统银行应用中更常见

  • 传统银行
  • 数字银行
  1. 个人间转账16%28%
  2. 银行卡冻结与用卡管理27%24%
  3. 虚拟卡与一次性卡5%28%
  4. 预算与消费分析13%48%

仅当应用代码中有该功能且其商店页面提及时才计入。Android 与 iOS 应用。数字银行:29 款应用(小样本);传统银行:848 款应用。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

下载包本身是什么样

在任何功能之前,先是下载包:它请求什么、有多大、多久更新一次、还能在多旧的手机上运行。

图 5.2

典型的 Android 银行应用申请 23 项权限,大小为 68 MB

  • 23典型应用请求的权限数
  • 68MB:典型应用的下载体积
  • 9每年发布次数(典型 Android 应用)
  • 99%的 Android 应用仍可安装在已不再更新的手机系统上

Android 应用。“典型”指中位数。旧系统:应用仍可安装在已不再获得安全修复的 Android 13 或更早版本上。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

更新频繁并不意味着漏洞更少:每三周或更短时间更新一次的 Android 应用中,有 63% 存在严重或高危漏洞,而间隔超过三个月的应用为 51%。更新日期来自应用商店评论中提到的版本。

AI 助手

AI 助手带来新的入口

银行正在为应用加入 AI 助手,每个助手都是一个可能遗留密钥的新地方。

3.7%


的银行应用内置 AI 助手

30% 的此类应用把密钥直接写在应用里,任何人都能取出。

图 6.1

配备 AI 助手的应用有 30% 在代码中留下密钥,未配备的为 19.9%

把应用想象成一扇前门:留在代码里的密钥,就像放在门口台阶上的钥匙。看看银行加入 AI 助手后会发生什么。

门垫下的钥匙代码中含有密钥无 AI 助手19.9%有 AI 助手30%1.5 倍 有了 AI 助手之后更常见

没有助手的应用同样会留下密钥,只是频率更低:五分之一。

助手:内置于应用的聊天机器人;与真人的在线聊天不计入。密钥:扫描确认的密钥,不含应用按设计内置的 Google API 密钥。没有应用含有 AI 服务的密钥。有 2 款应用调用 Google 的 AI「Gemini」,且两者都没有助手。大银行往往既有助手又有更多附加组件,因此这是关联而非因果。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

更新与隐私

应用的依赖库有多陈旧

应用由现成的代码库构建,其中多数已有更新的版本。我们统计了每个依赖库落后最新版本多少个版本。拖动刻度查看。

3


个版本的落后(典型应用的依赖库)

图 7.1

98% 的 Android 银行应用至少有一个落后 10 个版本的库

99%的应用,其依赖库通常落后最新版本 1 个版本 或更多。

Android 应用。每个依赖库都与其最新稳定版对比。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

不只是库:约每 20 家银行就有 1 家的自有应用曾出现公开安全漏洞(CVE),且大多是多年前的事。

商店标签与应用实际行为对比

64%

的 Android 银行应用在商店隐私标签中漏报了应用请求或内置第三方代码收集的数据

应用请求或内置的第三方代码会收集、但标签中却未列出此项的应用比例。

Android 与 iOS 对比

同一家银行,两款应用,两种安全水平

大多数银行都有 Android 和 iOS 两个应用。名字相同、标志相同,却常由不同团队开发。我们对每家拥有两个应用的银行,用同样的检查测试了这两个应用。

80%

的银行至少有一项检查中两款应用结果不一致

客户受到的保护取决于他们使用哪种手机,而攻击者只需针对较弱的那款应用。

图 8.1

在 3 项检查中,有 3 项 Android 应用不如 iOS 应用

该平台应用表现更差的检查项

Android 与 iOS 代码均能完整读取的银行,少于图 8.3 中两款应用均经扫描的银行。每行是一个问题,越靠右越差。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

逐家银行

同一家银行,同一项检查,不同的结果

一个圆是 Android 应用有该问题的银行,另一个是 iOS 应用有该问题的银行。重叠处表示两个应用都有。重叠区外的点是两个应用结果不同的银行:修好一个,另一个仍有漏洞。

图 8.2

80% 的银行,其 Android 与 iOS 应用至少在一项检查上结果不同

32 家(共 100 家):问题只存在于其中一款应用

  • 19 仅 Android
  • 16 两款应用
  • 13 仅 iOS
  • 52 均无

每个条形代表 100 家银行:依次为仅 Android、两款应用、仅 iOS、均无。数字表示两款应用结果不一致的银行数量。

以 100 家银行表示,由同时拥有两个应用的 75 家换算而来。圆的大小按比例绘制,一个点代表一家银行。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

双胞胎应用

同一家银行的两个应用:哪个更扛得住?

我们对152家银行的Android和iOS应用都做了扫描,并比较了每家银行的两个版本。 两部手机一起落下。在保护措施和扫描评分上,每格代表一家银行,在两个屏幕的同一位置,较强的应用一侧亮起。在严重缺陷上,每个红格是一款有严重缺陷的应用,按平台分别计数。

图 8.3

银行的 Android 应用有 54% 存在严重缺陷,其 iOS 应用为 34%

Android54%

iOS34%

每个红格是一款有严重或高风险缺陷的应用,按平台分别计数,未按银行一一对应。

两款应用都已扫描的 152 家银行。防护:两个平台共有的 9 项防篡改检测。扫描规则因平台而异,因此得分对比仅供参考。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

应用之外

攻击者无需打开应用就能发现的问题

应用商店里的假冒应用、相似的网址、任何人都能伪造的邮件、陈旧的服务器配置:攻击者在接触应用之前,就能凭公开信息摸清一家银行。我们查看了每家银行暴露在外的内容。

图 9.1

97% 的银行有被注册的相似网址,注册者可能是他人或银行自己

28%

的银行在应用商店中有其他发布者使用其名称的应用

在 Google Play、App Store 或 AppGallery 中使用银行名称、但由他人发布的应用(不含银行的合作方)。值得核查,但并非都是假冒应用。

已检查 486 家银行 · 公开来源与银行的公开网站。500 家银行,1,252 个银行网站。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

一家银行,数十个仿冒网址

一家典型银行有 28 个已注册网址与其自有网址只差一处。下面用一家虚构的银行展示它们是怎么做出来的。

图 9.2

54% 的仿冒网址采用同一种构造方式:缺失或重复字母

真实网址yourbank.com

已检查 486 家银行 · yourbank.com 是虚构的,用于演示方法。比例基于 4,132 个仿冒地址,按与真实地址的差异分类。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

服务器

后端位于何处

每个银行应用都要与服务器通信:服务器负责客户登录、转账和发送提醒。我们把应用中每家银行自己的服务器追溯到运行它们的网络。大多数在全球云网络上(如 AWS 或 Cloudflare),可能位于任何地方;其余在银行自己的网络上,主要在本国。

图 10.1

60% 的银行服务器位于大型全球云网络之后

每条线从该地区连到其银行自有服务器所在的国家。线越粗,占比越大。

84%

的 北美 银行服务器位于全球云网络上,可从任何地方响应

在其自有网络上的主机中,有 10% 位于北美之外。

银行自有网络上的主机,按国家

  1. 美国90%
  2. 荷兰8%
  3. 法国1%
  4. 其他国家1%

已检查 392 家银行 · 根据 Android、iOS 和 HarmonyOS 应用得出的银行服务器所在地。全球云可从任何地方响应,因此仅对银行自有网络上的服务器标注国家。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

当一家服务商宕机时

这些服务器大多运行在少数几家云服务商上。选择一家并将其关闭:每部手机是 100 家银行中一家的应用,显示其客户会失去什么。

图 10.2

如果 AWS 宕机,每 100 家银行中有 41 家的应用将部分瘫痪

  • 0 家银行失去整个应用:所有服务器都在这家服务商上
  • 0 家银行部分功能失效:部分后端运行在该服务商上
  • 100 家银行照常运行:没有服务器在其上

所有应用均正常运行。选择一家服务商使其宕机。

已检查 392 家银行 · 银行应用中提到的每台银行服务器由哪家公司运营。392 家银行至少有一台这样的服务器。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

64% 的银行至少把一台服务器放在销售 Web 攻击过滤(WAF)的服务商之后(Akamai、Imperva、Cloudflare 或 F5)。

当银行服务中断时

英国零售银行必须报告每一起导致服务中断或面临风险的重大事件。年复一年,大多数是 IT 故障而非攻击,许多源于一次出错的变更或供应商。

图 10.3

自 2018 年以来,英国零售银行报告了 3,271 起重大事件,其中网络攻击仅 147 起

所有事件的起因

整个银行业,未点名任何银行。“第三方”和“变更”表示事件的起因。*2026 年截至 7 月 9 日,数据未最终确定。

来源:英国金融行为监管局(FCA),零售银行上报的重大运营事件(FOI2026/01239)

自 2025 年以来,公开报道和监管机构在 33 个国家记录了银行服务中断;最长的一次让一家银行的移动应用停摆约 48 小时。

攻击者的目标名单

已在攻击者的目标名单上

银行木马是窃取登录信息的恶意软件。每种木马都带有一份它能仿冒的应用名单:名单上的应用一打开,木马就在上面显示假的登录界面。安全研究人员公开了这些名单,我们将其与本报告中的银行进行了比对。

图 11.1

最常见的银行木马瞄准了每 100 家银行中 35 家的应用

50 家(共 100 家)银行至少被列入一个木马的目标名单。 34 被列入三个或更多名单。

红色角标表示将该银行应用列入名单的木马家族数量。点击应用即可打开。

已检查 389 家银行 · 安全研究人员于 2019 至 2025 年公布的 47 份银行恶意软件目标应用名单,与银行的 Android 应用比对。上榜表示被盯上,并非已被感染。每部手机代表一家匿名银行:选取 100 家,使比例与全部 389 家一致。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

今年只有 2 起攻击活动使用了篡改过的真实银行应用(GoldFactory 和 Hirudo)。其余的都使用仿冒的假应用,或覆盖在真实应用上的假界面。

案例档案

2026 年的四起攻击,逐份档案

今年,安全研究人员报告了这些针对银行客户的攻击。每份档案逐步讲解一次攻击,再与我们在应用中的发现进行对比。资料来源和我们都不点名任何银行。

Android 银行木马

替换你的银行应用的木马

Hirudo 不止在银行应用上叠加假界面。它会删除真实应用,安装一个被篡改的副本,欺骗应用自身的安全检查。

来源: ThreatFabric, 2026 年 10 月
  • 42在其目标名单上的金融应用
  • 8已备好篡改副本的银行应用,来自 7 家银行
  • 1 行代码被加入每个副本,用于加载改写应用的工具

攻击过程

我们的数据显示

  • 44%的 Android 银行应用会检查是否为重新打包并重新签名的副本
  • 45%在自身代码中防范叠加假屏幕或无障碍功能滥用
  • 56%阻止截屏
  • 16%使用 Google 的 Play Integrity 检查

来自应用代码(图 2.1 和 3.1)。当恶意软件替换应用时,最好的防御是在银行自己的服务器上进行检查。

如何阻止

  • 在服务器上针对每个会话和敏感操作核验 Google 的 Play Integrity 结果。
  • 将手机的密钥证书与 Google 的吊销列表进行核对。
  • 在登录、账户找回、新增收款人和付款时,在服务器端保留反欺诈检查。
  • 把无障碍和截屏迹象作为风险信号使用,而不是唯一的拦截手段。

欺诈的代价

欺诈的代价,以及由谁买单

应用的弱点只是故事的一面,损失的钱是另一面。这些数字来自监管机构公布的数据表,而非我们的测试。它们描述的是整个市场,而不是我们扫描的任何一家银行。

图 12.1

在欧盟,每 100 欧元支付欺诈损失中有 66 欧元由客户自己承担

在欧盟全部支付欺诈中,每 €100 中有 €66 由客户自己承担。

  • €66客户
  • €22客户的银行或发卡机构
  • €12商户等其他方
  • €2,155每笔欺诈银行转账的平均损失
  • €20每支付 100 万欧元中的欺诈金额(所有支付类型)
  • 150每百万笔银行卡支付中的欺诈笔数

欧盟:欧洲银行监管机构 2025 年欺诈报告,2024 年数据,追回后的损失,按承担方划分。英国:支付监管机构,客户受骗付款的诈骗退款,2024 年 10 月 7 日至 2026 年 3 月 31 日。费用由付款银行和收款银行平均分担。

来源:EBA 和 ECB,支付欺诈报告(2025);英国支付系统监管局(PSR)

强验证减少欺诈,向境外汇款则使欺诈增加

按付款的批准方式和资金去向拆分的银行卡欺诈。

图 12.2

未经强身份验证的银行卡支付,欺诈是验证支付的 1.9×

每条管道都承载着客户向收款人和商户支付的同样 €100 万。途中漏出的金币就是被欺诈卷走的部分,收集在下方的玻璃杯中。

客户经每条管道支付 €100 万

2024 年的银行卡支付。来源:EBA 与 ECB 2025 年欺诈报告。

来源:EBA 和 ECB,支付欺诈报告

诈骗资金流向何处

在英国,监管机构会公布每家机构的客户转出了多少诈骗款,以及有多少诈骗款进入其账户。远高于基准线的机构收到的远多于转出的:犯罪分子在用它的账户收钱。

图 12.3

英国 11 家最大机构中,有 3 家收到的诈骗资金多于其客户汇出的金额

3 家机构(共 11 家)收到的诈骗资金多于其客户汇出的金额

英国支付监管机构,2024 年诈骗数据,早于 2024 年 10 月 7 日的退款规则。14 家最大银行集团中同时作为付款方和收款方的 11 家。未列出机构名称。

来源:英国支付监管机构,诈骗付款数据

索赔之后

图 12.4

报告因诈骗损失的资金中,有 88% 已获偿还

裁定所需时间82% 在 5 个工作日内98% 在 35 个工作日内

88% 的报告损失金额已获偿还

  • 12% 的钱再也没回来:小猪身上的洞
  • 88% 已追回:修补存钱罐的金缮

英国支付监管机构:2024 年 10 月 7 日至 2026 年 3 月 31 日的诈骗退款申请。为已退还的申请金额占比;未说明全额、部分或未获退款的申请数量。

来源:英国支付监管机构,诈骗付款数据

欺诈是应用安全问题转化为资金损失的环节。第 1 章中的保护措施,正是银行可以掌控的部分。

监管与成熟度

监管、规模与银行的公开表现

银行的监管机构不同,规模差别很大,对待安全研究人员的方式也不同。我们把这些因素逐一与在其应用中的发现进行了比较。

图 13.1

按监管机构及最大银行划分的应用安全

印度(RBI) 存在严重发现的应用最少:8%,全部银行为 18%。

已检查 444 家银行 · 银行按本国监管机构分组;全球最大的银行也单独成组。严重漏洞和通行密钥:应用占比。防篡改检测:典型应用具备的图 2.1 检测的比例。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

看起来更成熟的银行表现更好吗?

一些表明银行重视安全的迹象是公开的:告诉研究人员向哪里报告的 security.txt 文件、漏洞披露政策、为报告的缺陷付费的漏洞赏金计划、网站上的认证。选择一项,把银行分成两组并比较其应用。

图 13.2

有无各项迹象的银行中存在严重发现的比例

21 个百分点 拥有 security.txt 的银行中,存在严重问题的银行更少。

有 security.txt 30%
无51%

已检查 444 家银行 · 有已扫描应用的 444 家银行。每项指标都来自公开来源:银行网站、其安全联系文件、公开漏洞赏金计划以及银行声称的认证。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

10% 的银行在过去五年内有公开报道的数据泄露,信息来自泄露数据库、勒索软件泄露网站和监管备案。

同比变化

谁在改进,改进在哪里

每年测试的全部应用。每一行都是越低越好。

图 14.1

4 项指标中有 3 项在 2025 至 2026 年间有所改善

  • 2025
  • 2026

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

单个应用中最多的严重漏洞数:2025 年 19 个,2026 年 18 个。

今年新增

首次报告的检查项。2025 年报告未给出这些项的占比,因此暂无可比数据。

图 14.2

59% 的应用在手机上未加保护地存储敏感数据

  • 51%使用弱加密(如 MD5 或 ECB 模式)
  • 59%在手机上未加保护地存储敏感数据
  • 35%在不安全的内置浏览器中显示网页
  • 16%未经检查就打开指向应用的链接
  • 11%允许将数据备份到手机之外(允许备份)
  • 7%申请了看似并不需要的危险权限
  • 3%用外部输入拼接数据库查询(SQL 注入)
  • 1%可能被叠加的假屏幕欺骗(点击劫持)

Android 应用,Ostorlab 扫描:至少有一个此类低危及以上漏洞的应用。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

今昔对比:2025 年报告中同样给出的指标

与 2025 年报告相同的指标,一年之后的结果。大多数描述的是应用本身而非漏洞,请把它们看作变化,而不是好坏。

图 14.3

相同指标,2025 年至 2026 年

2025 年数据来自 2025 年报告。

来源:Ostorlab 对 500 家银行的 2,690 款银行应用的分析,2026 年

方法

测试方法

数据来源有两个。一是由 Ostorlab 读取和扫描的应用本身:下方五张卡片中的四张。二是公开信息,即第三张卡片:应用商店页面、银行网站、威胁报告和监管机构的统计表。

  1. 读取代码

    每个应用的构成:框架、第三方代码、权限、服务器、防护。全部应用。

  2. 扫描

    发现的问题按风险评级,对应 OWASP 移动标准。全部应用。

  3. 500 家银行

    公开数据

    应用商店页面、排行榜、证书、威胁报告以及银行的公开网站。全部银行。

  4. 保护检查

    代码中针对已解锁手机、假手机、篡改工具和重建副本的检查。Android。

  5. 客户保护

    代码中发现的登录、支付与防诈骗保护。所有应用。

范围. 仅限应用商店中的公开版本,未运行即读取。

我们扫描了 Android、iOS 和 HarmonyOS(华为 AppGallery)上的银行应用。

商店页面读取时间:2026 年 10 月 28 日至 11 月 9 日。

本报告使用的术语
API
一个程序向另一个程序请求数据或操作的方式。
SDK
应用内置的现成代码包,通常来自其他公司。
SMS
短信,这里指用于一次性登录验证码的短信。
OWASP
发布广泛使用的应用安全指南的非营利组织。
MASVS
OWASP 制定的移动应用安全要求清单。
PIE
将代码加载到内存随机位置、增加攻击难度的编译设置。
RELRO
启动后将应用部分内存设为只读的编译设置。
MD5
一种旧的数据指纹算法,已不再安全。
ECB
加密中会暴露规律的不安全模式;在欺诈章节中指欧洲中央银行。
OAuth
使用另一服务的账户登录的标准。
CVE
已知安全漏洞的公开编号。
HSTS
要求浏览器只使用安全连接(HTTPS)的网站设置。
DMARC
要求其他服务器拒收冒用银行地址邮件的邮件规则。
WAF
Web 应用防火墙:在攻击到达服务器前将其拦截的过滤器。
PSD2
欧盟支付服务指令,要求强客户认证。
DORA
欧盟关于金融机构数字运营韧性的法规。
EBA
欧洲银行管理局,欧盟的银行监管机构。
FFIEC
为美国银行监管机构制定统一检查标准的委员会。
PRA
英国审慎监管局,英国银行监管机构之一。
FCA
英国金融行为监管局。
GCC
海湾合作委员会:沙特、阿联酋、卡塔尔、科威特、巴林和阿曼。
RBI
印度储备银行,印度央行及银行监管机构。
PBOC
中国人民银行,中国的中央银行。
NFRA
国家金融监督管理总局,中国的银行监管机构。
G-SIB
全球系统重要性银行:由金融稳定理事会认定的全球最大银行之一。

历年版本

下载完整报告

共 54 页:全部图表、案例研究、分地区结果以及测试方法。