「A2B攻撃」は、2026年10月13日にNICT（情報通信研究機構）が注意をよびかけた攻撃のやり方です。同じ日に総務省も事業者むけに注意喚起を出しました。最近たて続けに起きている情報漏えいの原因の一つとされています。
この記事では、A2B攻撃とは何かを最初にひとことで説明し、そのあと身近な例、ねらわれる脆弱性、開発者がやるべき対策の順に、NICTと総務省の発表にそってまとめます。
A2B攻撃とは？ひとことで言うと
A2B攻撃（App-to-Backend Attack）とは、だれでも手に入る公開アプリを解析して、その裏で動いているサーバー（バックエンド）をねらう攻撃です。
NICTが確認したのはAndroidアプリを解析する例ですが、総務省は、同じ問題はiOSアプリやWebサービスでも起こりうるとしています。
攻撃の流れ
- 攻撃者が、ストアなどで公開されているアプリを手に入れる
- アプリを解析して、どのサーバーに、どんなAPI（アプリとサーバーがやりとりするしくみ）で通信しているかを調べる
- わかったAPIに合わせて、サーバーの弱いところをねらった攻撃をする
作る側からすると、「アプリの中だけで使っているつもりのAPI」のしくみが外から知られてしまい、そこをピンポイントでねらわれることになります。
アプリに穴がなくてもねらわれる理由
A2B攻撃で大事なのは、アプリそのものに脆弱性がなくても被害が起こりうるという点です。
NICTと総務省の発表では、サーバー側の認証・認可や入力チェックに不備があれば、不正アクセスや個人情報の漏えいにつながるおそれがあるとしています。アプリはただの「入り口の地図」として使われ、実際にねらわれるのはサーバー側です。
さらにNICTは、AIを使うことでアプリの解析や脆弱性さがしが速くなり、こうした攻撃がより多くのシステムに広がるおそれにも注意が必要だとしています。
身近なたとえ
お店の入口（アプリ）にはカギがかかっていても、裏口（API）の場所が地図（アプリの中身）に書いてあり、しかも裏口のカギがかかっていなければ、そこから入られてしまいます。A2B攻撃は、この「地図を読んで裏口をさがす」攻撃だと考えるとイメージしやすいです。
よくある例：IDを書きかえるだけで他人のデータが見える
NICTが重点的に点検するよう求めている脆弱性の一つが「IDOR／BOLA（認可の不備）」です。たとえば次のようなケースです。
- アプリは「自分の会員番号のデータ」を取得するAPIを呼んでいる
- 攻撃者がAPIのしくみを知り、会員番号の部分だけを別の番号に書きかえてリクエストを送る
- サーバーが「そのデータを見てよい人か」を確かめていないと、他人のデータが返ってしまう
アプリの画面では自分のデータしか表示しないようにしていても、サーバー側でチェックしていなければ守れません。
ねらわれている脆弱性
NICTの注意喚起では、とくに次の脆弱性を重点的に点検するよう書かれています。
- IDOR／BOLA（認可の不備）：IDなどを書きかえるだけで、ほかの人のデータが見られてしまう
- SSRF：サーバーに、本来アクセスさせてはいけない先へリクエストを送らせてしまう
- RCE：外からサーバー上で好きなプログラムを動かされてしまう
- SQLインジェクション：入力した値で、データベースを勝手に操作されてしまう
開発者がやるべき3つの対策（NICT）
NICTは、Androidアプリを公開している事業者にむけて、次の3つをお願いしています。
1. 侵害の確認
公開しているAPIやサーバーを洗い出し、アクセスログなどから、あやしいアクセスや情報の不正な取得がないかを確かめます。
2. 脆弱性の点検
上にあげた認可の不備、SSRF、RCE、SQLインジェクションなどの脆弱性や、設定の不備がないかを重点的に点検します。
3. 暫定的な緩和策
使っていないAPIを止める、アクセスを制限する、監視を強める、認証情報を無効にして発行しなおす、など必要な対策をとります。
覚えておきたい考え方
総務省は、「アプリなど利用者側からの通信は、信頼できるものとはかぎらない」ことを前提に、アプリ側の制御だけにたよらず、サーバー側できちんと認証・認可や入力チェックをすることが大事だとしています。
NICTも、「公開アプリは解析されるもの」と考えて、バックエンドサーバーの安全を守ることが大事だとまとめています。
開発者むけチェックリスト
発表の内容をもとに、自分のサービスで確認したいことを整理すると次のようになります。
- APIのリクエストごとに、サーバー側で「この人がこのデータを使ってよいか」を確かめているか
- アプリの中にAPIキーや認証情報を埋めこんでいないか
- 使っていない古いAPIが動いたままになっていないか
- 入力値をサーバー側でチェックしているか
- アクセスログを残し、あやしいアクセスに気づけるようにしているか
AIエージェントにも同じ考え方が必要
「外から来る入力は信用しない」「権限は必要なぶんだけ」という考え方は、AIエージェントでも同じです。AWSのAIエージェント基盤で報告された事例を、Amazon Bedrock AgentCoreとAgentCorruptionの記事でまとめています。
よくある質問
A2B攻撃はスマホを使う一般の人にも関係ある？
攻撃でねらわれるのはサービス側のサーバーなので、利用者が直接できる対策は多くありません。ただし、サービス側で情報漏えいが起きると利用者の情報がもれるおそれがあります。サービスからのお知らせを確認し、パスワードの使い回しをさけることが大切です。
iPhoneアプリなら大丈夫？
総務省は、同じ問題はiOSアプリやWebサービスでも起こりうるとしています。OSの種類にかかわらず、サーバー側の対策が必要です。
まとめ
- A2B攻撃は、公開アプリを解析して、その裏のサーバーをねらう攻撃
- アプリに穴がなくても、サーバー側に不備があれば情報がもれるおそれがある
- 守るカギは、アプリから来る通信を信用せず、サーバー側で認証・認可と入力チェックをすること
- ログの確認、脆弱性の点検、不要なAPIの停止などを早めに進める
くわしい攻撃のしくみやIoC（侵害指標）は、NICTの注意喚起（PDF）にのっています。
コメント