独立系ネオバンク、アプリセキュリティで後れ：79%対51%

当社の2026年調査では、ネオバンクのモバイルアプリセキュリティは従来型銀行を下回りました。特に独立系ネオバンクでは、大きな差が見られます。重大度が高またはクリティカルの検出結果が1件以上あるアプリの割合は、独立系ネオバンクで79.3%、従来型銀行で51.2%でした。 その差は28.1ポイントです。

アプリを事業の中心に据える銀行であれば、そのアプリの安全性には十分に力を注ぐ理由があるはずです。それでも、独立系ネオバンクのアプリに認証情報が埋め込まれている割合は、従来型銀行の2倍以上に上ります。パスキーやアプリのアテステーションの導入では先行しているにもかかわらずです。最新のセキュリティ機能と基本的な弱点が共存しています。

これらは、64か国の487行が提供する2,686本のアプリを対象とした、Ostorlabのモバイルバンキングアプリセキュリティレポート2026の調査結果です。最も大きな隔たりがあるのは、独立系ネオバンクとそれ以外の銀行の間でした。

差は28ポイント。資本関係が分かれ目

ネオバンクをひとまとめにすると、実態が見えなくなります。2種類のネオバンク全体では、61.1%のアプリに重大度が高またはクリティカルの検出結果があります。しかし、資本関係で分けると、まったく異なる状況が浮かび上がります。

銀行傘下のネオバンクは親銀行とよく似た結果を示しており、差を生んでいるのは独立系ネオバンクです。

独立系のグループは小さく、10行の29本のアプリで構成され、その約3分の1を1行のアプリが占めます。レポートでは、銀行ごとの重みを等しくした場合や、プラットフォームの構成を考慮した場合にも差が残ることを確認していますが、差の大きさは目安として捉える必要があります。差があるのは重大度が高の検出結果であり、クリティカルの検出結果の割合は3つのグループで同程度です。これらは配布済みのアプリに対するスキャナーの検出結果であり、実際の侵害発生率を測定したものではありません。

パスキーも、露出したシークレットも多い

独立系ネオバンクは、セキュリティチームが銀行に導入してほしいと考える保護策の一部で先行しています。パスキーAPIを組み込んでいる割合は37.9%で、従来型銀行の4.6%を上回ります。アプリまたは端末のアテステーションを利用している割合は48.3%で、従来型銀行では19.9%です。

一方で、Google APIキー以外の認証情報を埋め込んでいる割合も48.3%に上り、従来型銀行の19.8%を上回ります。重大度が高またはクリティカルのOAuthアカウント乗っ取りに関する検出結果がある割合は24.1%で、従来型銀行の6.1%の約4倍です。

パスキーはログインをフィッシングから守ることができます。しかし、アプリに同梱された秘密鍵を取り除いたり、別のOAuthフローを修復したりすることはできません。強力な保護策を追加しても、別の場所にある弱点が帳消しになるわけではありません。銀行のセキュリティチームにとって重要なのは、ログインから支払いまでの経路全体が攻撃に耐えられるかという問いです。

従来型銀行も安心はできない

比較的良い結果だったグループでも、アプリの約半数に重大な検出結果が残っています。サンプル全体では、51.5%に重大度が高またはクリティカルの検出結果があり、20.3%には本来秘密にすべき認証情報が埋め込まれ、41.1%には脆弱性が公開されているサードパーティコンポーネントが含まれています。

認証情報には、秘密鍵、クラウドのキー、サービストークンが含まれます。アプリは顧客の端末に配布されるため、その中に格納されたものは取り出せます。銀行のサービスを守るためのシークレットは、アプリ内で見つからずに済むことを前提としてはいけません。

Google APIキーは別に集計しています。多くはMapsやFirebaseとともに配布することを想定しているため、見つかっただけで漏えいとは判断できません。リスクはキーの制限設定によりますが、本調査ではその設定をテストしていません。見つかった認証情報は一切使用していません。

銀行自身のアプリが攻撃者の道具になる

最近の攻撃キャンペーンは、アプリの完全性が重要な理由を示しています。GoldFactoryは正規の銀行アプリを改ざんします。Gigabudはアプリを隠れた仕事用プロファイルに複製します。Hirudoは本物のアプリを改ざんしたコピーに置き換えます。信頼されている画面はそのままでも、背後のコードは攻撃者のために動作し得ます。

それでも、79.8%のアプリではアプリや端末のアテステーションが確認されず、被害者のスマートフォンから不正を行うためのリモート操作ツールを検知しているAndroidアプリは22.3%にとどまります。アプリのアテステーションは改ざんされたコピーの識別に役立ちますが、銀行にとって有効なのは、サーバーがその結果に基づいて対応する場合だけです。その適用状況はアプリ単体からは確認できません。

生体認証にも同様の精査が必要です。スキャナーは、Androidアプリの35.1%で回避可能な生体認証ログインフローを検出しました。指紋認証のプロンプトがどれだけ有効かは、それが保護する操作との結び付きによります。成否の結果だけを確認するフローは、スキップできてしまいます。重要な操作には、生体認証で利用可能になる暗号鍵を必須にする必要があります。

金銭面での深刻さは、すでに表れています。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本のアプリを分析しました。サンプルは、グローバルなシステム上重要な銀行29行を含む487行を対象とし、2025年版の5倍の規模です。サンプルと手法が変わっているため、両年の結果は経年変化を示すものではありません。

各アプリに対して、静的解析、自動高速スキャン、認証と支払いに関する16項目の制御チェックを実施し、銀行に関する公開データも確認しました。検出結果とは、配布済みのパッケージでスキャナーのルールに一致したことを意味し、悪用可能性の実証ではありません。アプリへの攻撃、ログインのテスト、見つかった認証情報の使用は一切行っていません。この手法ではサーバー側の保護策が見えない場合があります。読み取れるコードが必要なチェックでは、コードがパックされたアプリを除外しています。パスキーの全体結果の母数は2,586本、アテステーションは2,602本です。結果は集計値のみで、特定の銀行やアプリの名前は挙げていません。