独立数字银行的应用安全落后：79% 对 51%

在我们的 2026 年研究中，数字银行（neobank）的移动应用安全表现逊于传统银行。独立数字银行的差距尤为明显：79.3% 的应用至少存在一项高危或严重级别的发现，而传统银行应用的这一比例为 51.2%。 两者相差 28.1 个百分点。

以应用为业务核心的银行，理应有充分的理由把应用安全做好。然而，独立数字银行应用内嵌凭据的比例超过传统银行的 2 倍，即使它们在通行密钥和应用证明的采用上处于领先地位。现代安全功能与基础性弱点并存。

这些结果来自 Ostorlab 的《2026 移动银行应用安全报告》，研究涵盖 64 个国家 487 家银行的 2,686 款应用。最明显的分界，出现在独立数字银行与其他银行之间。

差距达 28 个百分点，股权归属是关键

把所有数字银行合并统计，会掩盖真实情况。两类数字银行合计有 61.1% 的应用存在高危或严重级别的发现，但按股权归属拆分后，却呈现出截然不同的图景：

传统银行旗下的数字银行与其母行表现相近，独立数字银行拉开了差距。

独立数字银行组的样本较小：来自 10 家银行的 29 款应用，其中约三分之一来自同一家银行。报告发现，在给予每家银行相同权重、以及考虑平台构成后，这一差距仍然存在，但差距的幅度仍应视为参考值。差异出现在高危级别的发现上；三个组的严重级别发现率相近。这些是扫描器在已发布应用中的检测结果，并非实测的数据泄露或入侵发生率。

通行密钥更多，暴露的凭据也更多

在安全团队希望银行采用的部分控制措施上，独立数字银行走在前面。37.9% 的应用集成了通行密钥 API，而传统银行应用仅为 4.6%。48.3% 使用了应用或设备证明（attestation），传统银行则为 19.9%。

然而，48.3% 的应用内嵌了 Google API 密钥以外的凭据，传统银行应用的这一比例为 19.8%。24.1% 的应用存在高危或严重级别的 OAuth 账户接管发现，而传统银行为 6.1%，前者接近后者的 4 倍。

通行密钥可以保护登录过程免遭钓鱼攻击，却无法移除随应用打包的私钥，也无法修复另一条 OAuth 流程。增加一项强有力的控制措施，并不能抵消其他位置的弱点。对银行安全团队而言，真正有用的问题是：从登录到支付，整条路径能否经得住攻击。

传统银行也没有多少理由庆祝

即使是表现较好的组，仍有约半数应用存在重大安全发现。在全部样本中，51.5% 的应用存在高危或严重级别的发现，20.3% 内嵌了本应保密的凭据，41.1% 带有已公开漏洞的第三方组件。

这些凭据包括私钥、云服务密钥和服务令牌。应用会分发到客户的设备上，任何打包在其中的内容都可能被提取。保护银行服务所需的密钥，不应依赖于在应用中保持隐藏。

Google API 密钥单独统计。许多本就需要随 Maps 或 Firebase 一起发布，因此发现此类密钥并不等于发生了泄露。风险取决于密钥的限制设置，而本研究没有测试这些设置。我们没有尝试使用发现的任何凭据。

银行自己的应用也可能成为攻击者的工具

近期攻击活动说明了应用完整性为何重要。GoldFactory 会修改正版银行应用。Gigabud 会将它们克隆到隐藏的工作资料中。Hirudo 会用经过修改的副本替换真正的应用。用户信任的界面可能依然如故，背后的代码却已为攻击者所用。

然而，79.8% 的应用未显示出使用应用或设备证明的迹象，只有 22.3% 的 Android 应用能够检测用于在受害者手机上实施欺诈的远程控制工具。应用证明可以帮助识别遭到篡改的副本，但只有服务器根据证明结果采取行动，才能真正帮助银行。仅凭应用本身，无法确认服务器是否执行了这些措施。

生物识别同样需要审视。扫描器在 35.1% 的 Android 应用中标记出了可绕过的生物识别登录流程。指纹提示的保护能力取决于它与所保护操作的关联方式：如果流程只检查“是或否”的结果，就可能被跳过。敏感操作必须要求使用通过生物识别检查后解锁的加密密钥。

经济损失已经显现。根据 UK Finance 的数据，2025 年英国授权推送支付诈骗损失中，301.8 百万英镑、即 52% 发生在移动银行渠道。这些损失是说明风险后果的另一项证据，并非被归因于本研究检测结果的损失。

下次发布前应该改变什么

对银行管理层而言，这一对比要求提供证据，证明各项防护措施能够协同发挥作用。工程和安全团队可以先从以下检查入手。这些检查取自报告的建议，并在报告中与 OWASP MASVS 建立了对应关系：

1. 从发布的应用中移除密钥。 将私钥和服务凭据保留在服务器端，只向应用提供有效期短、访问范围受限的令牌。
2. 修补依赖项中的已知漏洞。 为每次发布维护软件物料清单，并为修复存在严重漏洞的组件设定期限。
3. 测试从登录到支付的完整路径。 将敏感操作与硬件支持的密钥绑定，检查 OAuth 流程，并提供通行密钥。测试控制措施是否可以被绕过，而不只是检查代码中是否出现了相应 API。
4. 让服务器判定应用完整性。 在服务器端验证 Play Integrity 或 App Attest 的判定结果，并在验证失败时采取行动。在真机上使用当前的攻击者工具测试运行时防御。
5. 在关键时刻利用设备风险信息。 登录时检查补丁级别，并限制未打补丁设备上的高风险操作。在远程控制工具将合法会话转变为欺诈活动之前检测出它们。

下一次发布评审需要回答一个具体问题：团队能否证明，攻击者无法跳过保护账户或支付的检查？

阅读完整报告，了解银行类型对比、各国数据表、4 起攻击案例研究和全部 8 项建议措施。使用 Ostorlab for banking，测试您自己应用中的这些控制措施。

研究测量了什么

2026 年 10 月 28 日至 11 月 5 日期间，我们收集了 2,841 条银行应用上架信息，并分析了 Android、iOS 和 HarmonyOS 平台上的 2,686 款应用。样本覆盖 487 家银行，其中包括 29 家全球系统重要性银行，规模是 2025 年版报告的 5 倍。由于样本和方法发生了变化，两版结果不能用来判断同比趋势。

每款应用都经过了静态分析、自动化快速扫描、16 项身份验证与支付控制检查，同时我们还审查了银行的公开数据。一项发现意味着扫描器在已发布安装包中匹配到了一条规则，并不证明问题可被利用。我们没有攻击任何应用，没有测试任何登录，也没有使用发现的任何凭据。这种方法可能无法观察到服务器端的防护措施。需要可读代码的检查会排除加壳应用：通行密钥的总体结果以 2,586 款应用为基数，应用证明的结果以 2,602 款为基数。所有结果均为汇总数据，不点名任何银行或应用。