こんにちは。ランシステムのヒロ田中です。
買い物や予約、会員サービスなど、スマートフォンのアプリは日常生活に欠かせないものになりました。企業が顧客向けのアプリを提供する機会も増えています。
アプリのセキュリティというと、不正なアプリのインストールや、スマートフォン自体の脆弱性を思い浮かべるかもしれません。しかし、アプリそのものに問題がなくても、その裏側で動くサーバが攻撃され、情報漏えいにつながる可能性があります。
2026年10月13日、国立研究開発法人情報通信研究機構（NICT）は、国内で相次ぐ情報漏えい事案の原因の一つとして、「A2B攻撃（App-to-Backend Attack）」と呼ぶ手法を特定したと発表しました。
今回は、その仕組みと企業が確認しておきたい対策について紹介します。
公開アプリがサーバ攻撃の手掛かりになる
※NICTの公表内容を参考に、攻撃の仕組みを簡略化して示しています。
スマートフォンのアプリは、すべての処理を端末内で行うわけではありません。例えば、買い物アプリで注文履歴を表示するときには、インターネットを通じてサーバに問い合わせ、必要な情報を受け取っています。この情報のやり取りに使われる仕組みが「API」です。
A2B攻撃では、攻撃者が一般に公開されているAndroidアプリを入手・解析し、APIの接続先や通信の仕様などを調べます。そして、得られた情報をもとに、アプリの裏側にあるバックエンドサーバの弱点を狙います。
事業者が一般には公開していないつもりのサーバの仕様も、アプリを解析することで攻撃の手掛かりになる場合があります。サーバ側に認証や認可、入力値の検証などの不備があれば、アプリ自体に脆弱性がなくても不正アクセスや情報漏えいにつながりかねません。
今回確認されたのはAndroidアプリを手掛かりにする攻撃ですが、NICTはiPhone向けのアプリやWebサービスでも同様の問題が起こり得ると指摘しています。また、AIの活用によってアプリ解析や脆弱性の探索が効率化され、攻撃対象が広がる可能性にも注意を呼びかけています。
ログインできることと、情報を見てよいことは違う
ここで押さえておきたいのが「認証」と「認可」の違いです。認証は利用者が本人であることを確認する仕組みで、認可はその利用者がどの情報を閲覧し、どの操作を行ってよいかを判断する仕組みです。
IPA（情報処理推進機構）は「安全なウェブサイトの作り方」の中で、認証だけでなく、利用者ごとに操作できる範囲を適切に制限する認可制御の重要性を説明しています。
例えば、ログインした会員が自分の注文履歴を確認できるサービスを考えてみます。IPAは、サーバ側の認可制御に不備があると、注文番号を変更することで他人の注文情報まで閲覧できてしまう場合があると説明しています。
本来は、その注文情報を閲覧する権限が本人にあるかどうかを、サーバ側で確認しなければなりません。
パスワードの強化や多要素認証（MFA）は不正ログインへの対策として有効ですが、それだけで認可制御の不備が解消されるわけではありません。ログイン後にアクセスできる情報の範囲についても、サーバ側で適切に確認する必要があります。
委託先も含め、サーバとAPIの安全性を確認する
NICTはアプリを提供する事業者に対して、侵害の確認、脆弱性の点検、暫定的な緩和策の実施を推奨しています。
具体的には、公開しているAPIやサーバを把握してアクセスログを確認し、認可制御や入力値の検証などに問題がないかを点検します。必要に応じて、不要なAPIの停止やアクセス制限、監視の強化も検討します。
特に、外部の開発会社にアプリやWebシステムを委託している企業では、アプリの動作確認だけでなく、サーバ側の安全性を誰が、どのように確認しているのかを把握しておきたいところです。公開後の点検や、不審なアクセスが見つかった際の対応体制も確認しておく必要があります。
A2B攻撃は、これまで知られていなかった新しい脆弱性を利用するというより、公開アプリの解析を手掛かりに、サーバ側に存在する弱点を狙う手法です。
アプリが正常に動いていることと、サービス全体が安全であることは同じではありません。開発時だけでなく、公開後もサーバやAPIの安全性を継続して点検することが、情報漏えいを防ぐうえで重要だと考えます。