公開アプリからAPIが狙われる「A2B攻撃」 運営者が点検するサーバー側の穴
情報通信研究機構（NICT）は2026年10月13日、公開Androidアプリを解析して接続先APIや仕様を調べ、対応するバックエンドサーバを狙う手法を「A2B攻撃（App-to-Backend Attack）」として注意喚起しました。アプリ自体に欠陥がなくても、サーバー側の認証・認可や入力検証に不備があれば情報漏えいにつながり得ます。NICTは事業者に、公開API・サーバーの棚卸しとログ確認、認可不備などの点検、不要APIの停止・アクセス制限・監視強化・資格情報の更新を勧めています。これは個々のサービスが攻撃を受けたという診断ではなく、公開アプリを提供する事業者向けの確認項目です。アプリ利用者はアプリを削除するだけで防げる問題ではなく、サービス運営者へ告知や影響情報を確認するのが現実的です。
- スマートフォンアプリの開発・運用担当者
- Web API・バックエンドの管理者
- セキュリティ委託先を管理する事業者
アプリの接続先を隠すだけではなく、APIを提供するサーバーの認証・認可、ログ、不要機能の停止を運営者が点検します。
身近な事例を知る
自社アプリのコードは非公開なのに、API経由の侵入が心配
スマートフォンアプリを提供しています。アプリの通信先やAPI仕様を公開していないため安全だと思っていましたが、NICTのA2B攻撃の注意喚起を見て、何を点検すべきか分かりません。
あなたならどうする？
まず一つ以上選んでから確認してみてください。
推奨される行動- 公開APIを棚卸しし、サーバー側の認証・認可を点検してログを監視する
選んだカードの表示を見ながら、今回はどの行動が安心につながるか確認できます。
APIのURLや通信仕様を秘密にするだけでは防御になりません。運営者は公開APIを一覧化し、利用者ごとの認証・認可、入力値検証、ログ監視を確認します。不要なAPIは停止し、必要に応じてアクセス制限や資格情報の無効化・再発行を行います。技術点検は管理するシステムに限り、担当者または契約した専門家が実施してください。
確認ポイント
アプリ解析からバックエンドを狙う攻撃経路
NICTは、一般公開されたAndroidアプリを解析してAPIや接続先を調べ、その情報を使ってバックエンドサーバーへ攻撃する手法をA2B攻撃と説明しています。
アプリに欠陥がなくてもサーバー側の弱点が残る
NICTのCYNEXレポートは、バックエンドの認証・認可や入力検証の不備が不正アクセス・情報漏えいにつながり得るとしています。APIが非公開であることを安全性の根拠にしません。
まずAPI・サーバーの棚卸しとアクセスログ確認
NICTは公開APIやサーバーを洗い出し、アクセスログから不審なアクセスや情報の不正取得がないか確認するよう事業者に勧めています。
点検対象の例は認可不備、SSRF、RCE、SQLインジェクション
NICTはAPIのIDOR/BOLA等の認可不備や、SSRF、RCE、SQLインジェクションなどを重点的な点検対象として示しています。ここでは攻撃手順ではなく、管理下のシステムでの専門的な診断項目として扱います。
暫定対応にはAPI停止や制限・資格情報の更新も含む
NICTは不要なAPIの停止、アクセス制限、監視強化、認証情報の無効化・再発行を緩和策として紹介しています。具体的な変更はサービス影響を評価できる責任者が実施します。
AIは探索効率化の可能性として言及
NICTはAIの活用でアプリ解析や脆弱性発見が効率化される可能性に注意を促していますが、個別事案のすべてでAIが使われたと断定しているわけではありません。
現時点での見立て
NICTの注意喚起はAndroidだけでなく、iOSアプリやWebサービスのバックエンドAPIにも同様のリスクがあり得ると説明しています。事業者は公開APIの棚卸し、権限・入力検証の点検、ログ監視、必要な暫定制限を行い、技術判断は管理者や専門事業者へ委ねます。
安全な対処方法
安心につながる行動
- 自社アプリとWebから呼び出されるAPI・サーバーを台帳化し、所有部署・認証方式・公開範囲を記録する棚卸しがないと不審ログ確認や不要APIの停止対象を特定できません。
- アクセスログから通常と異なる大量照会、他利用者のデータ参照、想定外の接続元などをセキュリティ担当と確認するNICTは不審アクセスや情報の不正取得がないかログを確認するよう推奨しています。
- 管理下のAPIに対して、利用者単位の認証・認可、入力値検証、権限境界を専門担当者または委託先に点検してもらうNICTが示す主な確認対象に認可不備と入力検証関連の脆弱性があります。
- 利用されていないAPIを止め、必要な場合はアクセス制限・監視強化・資格情報の無効化や再発行を検討するNICTの注意喚起に挙げられた暫定的な緩和策です。
- 個別システムの診断は、所有者の許可を得た環境で社内担当者または契約したセキュリティ事業者に依頼するNICTは個別システムの診断を行わないと明記し、専門的な相談先を案内しています。
避けたい行動
- アプリの通信先URLを難読化すればサーバーも安全だと判断する公開アプリから通信先や仕様が解析される可能性があり、サーバー側の認証・認可が必要です。
- 自社の許可や範囲を確認せず、公開アプリや第三者APIに対して診断・攻撃テストを実行する無許可のテストは第三者システムへ影響を与え、法的・運用上の問題になります。
- NICTが注意喚起を出したことだけを理由に、自社が侵害されたと断定するこれは一般的な手法と対策の注意喚起であり、個々のシステムの診断結果ではありません。
- AIがすべてのA2B攻撃を実行した、または攻撃者がAIを使ったと断定するNICTはAIによる探索効率化の可能性に言及しており、個別事案の使用確認とは区別が必要です。
AIの前向きな活用
API台帳を開発・運用・委託先で共有する
アプリのリリースごとにAPIの持ち主、権限設計、監視ログ、停止判断の担当者を更新すると、脆弱性注意喚起を具体的な点検作業へつなげやすくなります。
- 公開APIと不要エンドポイントを定期的に棚卸しする
- 認可・入力検証のテストをリリース工程へ加える
- 緊急時のAPI制限と認証情報更新の責任者を決める
今回、覚えておきたいこと
公開アプリの通信先は知られる前提で、運営者はAPIの権限・ログ・不要機能を点検する。
情報源
- 〖注意喚起〗 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」（外部リンク） 国立研究開発法人情報通信研究機構（NICT） その他
- 〖注意喚起〗相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」（外部リンク） NICT サイバーセキュリティネクサス（CYNEX） その他
誠主任からひとこと