A2B攻撃とは？総務省・NICTが注意喚起した攻撃手法とAPIセキュリティ対策

2026年10月13日には、総務省と情報通信研究機構（NICT）がA2B攻撃への注意喚起を出しました※1。

A2B攻撃（App-to-Backend Attack）とは、公開されているアプリを解析して接続先のサーバーやAPIを特定し、アプリを介さずにバックエンドへ直接リクエストを送って攻撃する手法です。注意したいのは、アプリ自体に脆弱性がなくても、サーバー側の認証・認可に不備があれば情報漏えいが起きることです。

この記事では、A2B攻撃の仕組みと、情報漏えいが起きる原因、企業が優先して取り組むべきAPIセキュリティ対策を解説します。

A2B攻撃はどのような流れで進むのか

A2B攻撃は、次の4段階で進みます。

1. 公開アプリを入手して解析する
2. 接続先のサーバーやAPIを特定する
3. アプリを介さずに、APIへ直接リクエストを送る
4. サーバー側の不備を悪用し、データを取得する

NICTは、国内で相次ぐ情報漏えいの原因の一つとしてこの手法に注意を促し、総務省も事業者や関係団体に対策の徹底を求めています※1。 Androidアプリに限らず、iOSアプリやWebサービスでも、APIに外部からアクセスできる構成なら同じリスクがあります。

なぜアプリに脆弱性がなくても情報漏えいが起きるのか

会員向けの予約アプリを例に考えます。利用者が予約履歴を開くと、アプリはサーバーに次のようなリクエストを送るとします。

GET /api/members/1024/reservations
Authorization: Bearer <access_token>

画面には自分の予約しか出ないため、アプリの操作だけでは問題が見つかりません。しかし攻撃者は、アプリを解析してこのリクエストの形を知り、会員IDを1025に書き換えてAPIへ直接送ります。サーバーが「ログイン中の利用者が、会員1025のデータを見てよいか」を確認していなければ、他人の予約情報がそのまま返ります。

このような不備を、認可の脆弱性（IDOR / BOLA）と呼びます。 問題はアプリではなく、サーバー側の認可処理にあります。 総務省の注意喚起も、アプリから届く通信を無条件に信頼せず、サーバー側で認証・認可や入力値の検証を行うよう求めています※1。

AIによってA2B攻撃のリスクはどう変わるのか

AIを使えば、アプリの解析や脆弱性の探索を効率よく進められます。調査の手間が下がれば、攻撃者は有名なアプリだけに対象を絞る必要がなくなります。自社の公開アプリやAPIも攻撃対象になりうる前提で、対策を進めることが重要です。 AIによる攻撃の自動化は「AI攻撃の自動化で増えるセキュリティ事故と、APIの脆弱性診断」でも解説しています。

企業が優先して実施すべきA2B攻撃への対策

対策の中心は、アプリの中身を隠すことではなく、バックエンドのAPIを点検することです。

1. APIの認証・認可を点検する

認証は「誰がアクセスしているか」、認可は「その利用者が何をしてよいか」を確かめる仕組みです。ログイン機能があっても、利用者ごとの権限を確かめていなければ情報は漏れます。

会員情報・注文履歴・ファイルのダウンロード・管理者向けの操作など、IDを指定してデータを扱うAPIから優先して点検します。権限の異なる2つのアカウントを用意し、許可されていないデータを取得・変更できないことまで確認します。

2. 入力値の検証をサーバー側で行う

アプリから送られた値をそのまま信頼すると、想定外のデータが処理されたり、SQLインジェクションなどにつながったりします。値の形式や範囲をサーバー側で検証し、アプリ側の入力チェックだけに頼らないようにします。

3. APIの公開範囲を見直す

内部向けのAPIや管理画面のAPIをインターネットに公開していないか、古い版のAPIが動き続けていないかを確認します。不要なAPIは止め、管理用のAPIはアクセス元を制限します。ただし、アクセス元の制限やWAFの導入だけでは、認可の不備は解消しません。

4. ログを確認し、不審なアクセスを検知する

APIのアクセスログを確認し、短時間の大量リクエストや、同じアカウントから多数の異なるIDへのアクセスがないかを調べます。 NICTの注意喚起でも、アクセスログ等の調査による侵害の確認が推奨されています※1。

脆弱性診断でどこまで確認できるのか

A2B攻撃への備えとしては、アプリと接続先のAPIを対象にした脆弱性診断が有効です。主に次の項目を確認します。

診断項目	確認する内容
認証	未認証の利用者が保護対象のAPIを使えないか
認可	他の利用者のデータを取得・変更できないか
入力値の検証	想定外の入力で不正な処理が実行されないか
公開範囲	不要なAPIや管理用の機能が外部に公開されていないか
情報の露出	エラーの応答などから機密情報が漏れていないか

診断ですべての脆弱性が見つかるとは限らないため、見つかった問題を修正したあとに再診断します。診断の種類と選び方は「脆弱性診断とペネトレーションテストの違い」で整理しています。

まとめ

1. APIの認証・認可を点検しましょう。
   他の利用者のデータにアクセスできないかを確認します。
2. 入力値の検証をサーバー側で行いましょう。
   アプリ側の制御だけに頼らないようにします。
3. APIの公開範囲を見直しましょう。
   不要なAPIや管理機能が外部に公開されていないかを確認します。
4. ログと監視の仕組みを整えましょう。
   不審なアクセスを検知し、調査できる状態にします。
5. 脆弱性診断と再診断を実施しましょう。
   問題を見つけて修正し、対策が効いているかを確かめます。

弊社のマルゴト DXセキュリティでは、公開アプリの接続先となるAPIの脆弱性診断から、修正・再診断までを支援しています。公開中のアプリやAPIに不安がある場合は、無料相談からお問い合わせください。

出典

※1 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（公開アプリの解析情報を悪用した攻撃への注意喚起）」（2026年10月13日）