2026年10月、国内では個人情報の大量漏洩の公表が相次ぎ、個人情報保護委員会（10月7日）、JPCERT/CC（10月8日）、内閣官房国家サイバー統括室とIPA（10月9日）、総務省とNICT（10月13日）が続けて注意喚起を公表した。11月5日には、国家サイバー統括室が事業者向けの対策をあらためてまとめている。中でもNICTが「A2B攻撃」と名付けた手口は、公開アプリの解析を起点にバックエンドのAPIを狙うもので、アプリ自体に脆弱性がなくても被害につながりうる。本稿では、A2B攻撃の仕組みと、NICTが示した対策をAPIの側からどう進めるかを整理する。
A2B攻撃とは何か
NICTの脅威情報分析チームLETTICEは10月13日、国内で相次ぐ情報漏洩事案の原因の一つとして、一般に公開されているAndroidアプリを解析し、その情報を悪用して接続先のバックエンドサーバを攻撃する手法を特定し、「A2B攻撃（App-to-Backend Attack）」(1)と名付けた。
LETTICEが確認した事例では、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手して解析し、接続先のサーバ、APIの構成、エンドポイント、通信に使うパラメーターを割り出していた。そのうえで、サーバごとの構成やAPIの仕様に合わせて攻撃内容を変えていた。認証不要のAPIだけでなく、ログイン後に使うAPIも標的になっていた。
LETTICEは、攻撃者が主に探索・悪用する脆弱性として、SSRF、RCE、SQLインジェクション、IDORの4つを挙げている。このうちIDORはBOLA（Broken Object Level Authorization）とも呼ばれ、会員IDなどの識別子を書き換えるだけで他の利用者の情報を取得できてしまう認可の不備だ。BOLAは、2023年に公開されたOWASP API Security Top 10でも最初の項目（API1:2023）に位置付けられている。
アプリを解析してAPIの仕様を割り出す手法自体は新しいものではない。アプリのプログラムをリバースエンジニアリングで読み解く方法や、端末とサーバの間にローカルプロキシを挟んで通信を観察する方法は、以前から知られている。NICTは、AIによってアプリの解析や脆弱性の探索が効率化し、攻撃がさらに広範に及ぶ可能性を指摘している。
NICTは、公開アプリの解析を完全に防ぐことは困難であり、攻撃者に内部構造やAPIの仕様を把握されても不正アクセスを許さないよう、サーバ側で認証・認可や入力値検証を徹底することが重要だとしている。同じ手法はiOSアプリやWebサービスのAPIでも悪用されうるため、自社で開発する企業だけでなく、開発・運用を委託している企業も点検の対象になりうる。対策の焦点は、アプリではなくAPIにある。
11月5日に内閣官房国家サイバー統括室が公表した事業者向けの対策(3)も、A2B攻撃を名指しで取り上げている。同文書は、ウェブアプリやモバイルアプリが利用するバックエンドAPIについて、認証・認可の堅牢な実装、厳格な入力値検証、認証情報の安全な管理、異常アクセスの検知・制御を求めている。また、標的の調査や侵害にAIが使われている可能性が高いとし、従来の脆弱性診断で比較的低いと評価されたリスクが組み合わされ、侵入の原因となった可能性のある事例もあると指摘している。
なぜ既存の対策だけでは見つけにくいのか
IDOR（BOLA）を悪用するリクエストは、正規のアプリと同じ形式で、正規に発行された認証情報を使って送られることがある。リクエスト単体では、パラメーターの値が他人のIDに置き換わっているだけで、不審な文字列を含まない。そのため、WAFのようにリクエスト単位で検査する対策だけでは見分けにくい。
見つけるには、「このユーザーがこのIDのデータを取得するのは業務上正しいか」「1人のユーザーが短時間に多数のIDを指定していないか」といった、通信の文脈を見る必要がある。個人情報保護委員会が10月7日に追加したAPI悪用の事例 (2)でも、会員IDが連番だったことや、アクセス回数に制限がなかったことが大量漏洩の原因に挙げられている。
もう一つの課題は、点検の対象から漏れるAPIだ。アプリの旧バージョンが使い続けているAPI、検証環境、部署ごとに作られたAPIなど、管理台帳に載っていない「シャドーAPI」は、攻撃者がアプリの解析で見つけても、提供者側は把握していない。NICTも、旧バージョンを含むAPIやサブドメイン、検証環境まで公開範囲を洗い出すよう求めている。
NICTの推奨対策とCequenceの対応
NICTは、侵害の確認、脆弱性の点検、暫定的な緩和策を早急に実施し、恒久的な対策としてバックエンドサーバ側の設計・実装を見直すよう推奨している。それぞれの項目に対して、Cequence API SecurityとCequence Bot Managementは、実際のAPI通信の分析で次のように対応する。
AIによって攻撃側の解析や探索が効率化されうる以上、防御側も人手の分析だけでは追いつかない。Cequenceは、攻撃が疑われる時間帯と平常時の通信を機械学習で比較し、ヘッダーの組み合わせやパラメーターの特徴など、攻撃に特有の差異を見つけ出して対策ポリシーを自動作成する。NICTも攻撃者がアプリを介さずにAPIを直接操作できると指摘しており、そうした通信に表れうる正規アプリとの挙動の違いが、機械学習による検知の手がかりとなる。国家サイバー統括室も、AIを活用した攻撃に対応するため防御側でもAIの活用を積極的に検討するよう求める一方、AIによる評価結果は根拠や妥当性を確認し、最終的な判断は人が行うべきだとしている。自動作成されたポリシーは、既定ではお客様による内容確認を経て有効化する。
なお、Cequenceによる分析の対象は、実際に観測できた通信に限られる。SSRFやSQLインジェクションなど実装上の脆弱性については、国家サイバー統括室も求めているように、公開前の脆弱性診断やペネトレーションテストなどと組み合わせて点検するのが望ましい。
まずは自社APIの点検から
Cequenceは米国で提供してきた「APIセキュリティ・リスクアセスメント」を、10月19日から日本国内で提供を開始した。お客様のAPI通信をCequence API Securityで分析し、主に次の点を評価する。
• APIの棚卸し（シャドーAPIの把握）
• 認証・認可の不備に関連するリスクの可視化
• 個人情報などの機微情報の把握
• 優先度を付けた改善策の提示
期間は計画から報告までで通常4〜6週間程度。成果物は、観測した通信に基づくAPIインベントリ・API仕様と、リスク評価・改善提言レポートの二つ。レポートは日本のチームが日本語で提供する。継続的な保護が必要なお客様には、保護機能を別途有償オプションとして提供する。
アプリは解析されうるという前提に立ち、APIの側で守りを固める。その第一歩として、自社のAPIが何を返し、誰がどのデータにアクセスできるのかを、実際の通信で確かめておきたい。
お問い合わせ：dl-sales-japan@cequence.ai
出典：
(1) NICT【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」
https://cynex.nict.go.jp/pdf/library/lettice/261013-01.pdf
(2) 個人情報保護委員会 「不正アクセスによる個人データ漏えい防止のための注意喚起」（2026年10月7日）事例9
https://www.ppc.go.jp/files/pdf/261007_shiryou-2.pdf
(3) 内閣官房国家サイバー統括室 「個人情報の漏えい等につながる不正アクセスへの対策について ～ウェブサイトやモバイルアプリに関する基本的な対策の徹底～」（2026年11月5日）
(4) https://www.cyber.go.jp/pdf/press/261105_taiou.pdf