A2B攻撃とは？ アプリ解析から情報が盗まれる仕組みとAPIの守り方

A2B攻撃とは？ アプリを手がかりにサーバーを狙う

A2Bは「App-to-Backend Attack」の略だ。NICTの説明では、攻撃者は公開されたAndroidアプリからAPIの接続先や仕様を調べ、バックエンドと呼ばれる裏側のサーバーに攻撃する。APIは、会員情報の取得などをアプリがサーバーに依頼する窓口と考えるとわかりやすい。[1]

アプリには、通信相手を知るための情報が必要になる。その情報を調べられたとき、サーバーが要求を受け付ける条件に不備があると、不正な取得や操作につながり得る。利用者の端末上のアプリに問題がなくても、サーバー側の認証・認可・入力確認に不備があれば危険が残るというのが、今回の注意喚起のポイントだ。[1]

次の区別が、発注側と開発側の会話の出発点になる。

確認するもの	会員サービスでの意味	サーバー側に必要な判断
認証	誰がログインしたか	認証情報は正しく、有効か
認可	その人に何を許すか	この会員のこの情報を、この操作で扱ってよいか
取得範囲	どれだけの情報を返すか	業務に必要な項目・件数に収まっているか

たとえば会員Aがログインできても、会員Bの住所を読む権限まであるわけではない。これは仕組みを説明するための仮例だ。ログインの成功とは別に、対象データごとの許可を確かめる必要がある。

AIを使う攻撃で、何が確認された？

JPCERT/CCは10月15日、調査した攻撃元サーバーで、AIを使って既知の脆弱性を探し、API経由の攻撃などを行っていたと報告した。Androidアプリの解析に関するファイルやツールの痕跡も確認している。調査対象には、日本以外の地域に向けたサービスを狙うものも含まれていた。[2]

ここから言えるのは、AIが攻撃側の調査や作業に使われていたことだ。国内のすべての漏えいがAIによるものだった、特定企業の被害がこの手法だった、攻撃が完全に無人化された、とまでは言えない。

JPCERT/CCの10月8日公開の注意喚起でも、扱う情報は断片的で、すべての事案が同じ手口ではないとしている。被害を出した企業名と、技術報告の攻撃手法を、根拠なく結びつけないことが必要だ。[3]

事業者にとっての実務的な意味は、攻撃者が通信先や処理を調べてくる前提で、サーバーの許可条件を見直すことにある。「画面ではできない操作だから」という理由だけで安全と判断しない。

ログインできる人にも、データごとの権限確認がいる

OWASPのAPIセキュリティ資料では、認証済みの利用者であっても、本来アクセスできないデータを扱えてしまう問題を「BOLA」として整理している。対策の中心は、要求されたデータにその利用者がアクセスできるか、サーバー側で毎回確認することだ。[4]

会員サービスの確認なら、単に「ログインなしでは取得できない」テストだけでは足りない。自社が管理する検証環境にダミーの会員を用意し、会員Aから会員Bのデータを取得・更新できないことも確かめる。法人ごとにデータを分けるサービスなら、別法人の情報も同じように確認する。

画面上で管理ボタンを隠していても、通信窓口で操作を拒否できるかは別の問題だ。OWASPのREST向けガイドも、APIの各窓口でのアクセス制御や、許可する操作の制限を求めている。[5]

発注側が確認したいのは、抽象的な「認証対応済み」という回答だけではない。たとえば、次のような検証結果だ。

• 他の会員の情報：閲覧だけでなく、更新・削除・一覧出力も拒否されるか。
• 管理者専用の操作：一般会員や退職した担当者の権限では実行できないか。
• APIの直接利用：アプリの画面を通さない要求でも、同じ権限確認が働くか。

これらは本記事で整理した確認例であり、個別サービスへの診断結果ではない。検証は所有者の許可した環境・範囲で行い、公開サービスや実在会員の情報を無断で試さない。

APIキーを隠すだけで、安全になる？

APIキーを持っていることだけで、会員情報の一括取得や管理操作まで許していないかを確認したい。OWASPのREST向けガイドは、機密性の高い資産を守る際に、APIキーだけへ依存しないよう求めている。[5]

すべてのキーが同じ性質というわけではない。公開を前提とする識別用のキーと、特権操作を許す秘密の認証情報は分けて扱う必要がある。後者を配布するアプリへ入れ、難読化だけで守る設計は見直したい。鍵や認証情報には、利用範囲、保管場所、更新・失効の手順まで必要になる。[6]

鍵を交換しても、権限確認の不備が残れば同じ問題を繰り返す恐れがある。逆に、設計の修正を待つ間に漏えいした鍵が使われ続けることも避けたい。どの鍵を止めると何が止まるかを把握し、暫定対処と恒久修正を組み合わせて進める。

アプリの外注先に、何を確認すればよい？

IPAは10月9日、外部公開アプリの点検に加え、API連携を含む構成要素ごとの管理・権限や、ログの取得内容・保持期間の見直しを呼びかけた。システムの全体像と、調査に使える記録を持つことが出発点になる。[7]

以下は、公表ガイドをもとに編集部が整理した打ち合わせ項目だ。製品名だけを確認するより、対象・担当者・確認結果を残しやすい。

確認したい問い	開発・運用担当者と確認するもの
本番・旧版・管理用APIを把握しているか	接続先の一覧、利用目的、廃止予定、管理者
利用者ごとの権限をどこで判定するか	サーバー側の設計と、ダミー会員による検証結果
秘密の認証情報がアプリに入っていないか	鍵の用途、保管場所、有効期限、失効手順
大量取得や不審操作に気づけるか	制限する操作、監視ログ、通知先、対応時間
問題が見つかったら誰が止めるか	API停止・鍵失効・顧客案内の責任者と連絡先

外部URLを読み込む機能にも注意が要る。サーバーに意図しない宛先へアクセスさせる「SSRF」という問題があるためだ。OWASPは、許可する宛先の検証などを求めている。外部サービスへの接続は必要な機能でもあるので、一律に止める前に、機能と接続先の条件を確かめたい。[8]

レート制限も、権限確認の代わりにはならない。正しい権限で必要な情報だけを返す仕組みと、短時間の大量実行を抑える仕組みは、役割が異なる。異常を見つけた場合は、記録を失わないようログの保全を含めて担当者や専門機関と相談し、影響に応じた遮断や認証情報の失効を進める。[3]

本記事は、アプリ・APIの設計と運用の確認に焦点を当てた。日本で相次ぐサイバー攻撃、何が起きている？ 2026年秋の被害と対策を整理では、最近の被害事例と、企業・利用者それぞれの対応をまとめている。

まとめ

• A2B攻撃は公開アプリを手がかりにサーバーを狙う。アプリの安全性だけでなく、サーバーが許す取得・操作の範囲を点検する必要がある。
• AIの悪用は最新調査で確認されたが、国内の全被害や完全自律化を示すものではない。確認された事実と推測を分けて対策を考える。
• 発注側も、APIの一覧、権限の検証結果、鍵の失効、監視と初動の担当者を確認できる。対策製品の導入だけで判断せず、実際の許可条件と運用を確かめたい。

出典・参考

1. NICT「相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」（2026年10月13日）
2. JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
3. JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日、9日更新）
4. OWASP「API1:2023 Broken Object Level Authorization」（2023年版）
5. OWASP「REST Security Cheat Sheet」
6. OWASP「Secrets Management Cheat Sheet」
7. IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（2026年10月9日）
8. OWASP「Server Side Request Forgery Prevention Cheat Sheet」

資料確認日：2026年10月16日。カバー写真はコード画面のイメージであり、攻撃用コードではありません。写真：ThisIsEngineering／Pexels（Pexels License）。