自社のSaaSやWebサービスで、公開しているAPI、旧バージョンのAPI、検証環境をすべて把握できているでしょうか。ログの保存先と、不審なアクセスを調べる担当者も併せて確認してください。
スマートフォンアプリは、画面だけで完結しているわけではありません。裏側では、会員情報や注文履歴などを管理するサーバと、API（アプリとサーバの間で情報をやり取りする窓口）を通じて通信しています。
2026年10月13日、国立研究開発法人情報通信研究機構（NICT）は、公開されているAndroidアプリを解析し、そこから得た情報を使って接続先のサーバを攻撃する手法について注意喚起しました。NICTは、この攻撃を「A2B攻撃（App-to-Backend Attack）」と呼んでいます。
公開アプリは誰でも入手し、調べることができます。アプリの仕組みを知られても、サーバ側で不正な要求を拒否できる設計と運用が必要です。
この記事でわかること
- A2B攻撃が、公開アプリを手がかりにサーバを狙う仕組み
- Androidアプリがなくても点検が必要な理由
- 認証と認可の違い、点検する4つの弱点
- 侵害確認・脆弱性点検・暫定対策の進め方
- 専任担当者がいない企業で、対策を継続運用にする方法
A2B攻撃とは？
A2B攻撃は、攻撃者が公開アプリを手がかりにして、その裏側にあるバックエンドサーバを狙う攻撃です。
たとえば会員向けアプリには、ログインや注文履歴の取得に使う接続先が含まれます。攻撃者はアプリを解析し、APIへ送る要求の形式や項目を調べます。
アプリの画面に管理機能が表示されていなくても、通信先やAPIの仕様がアプリ内に含まれていれば、解析によって手がかりを得られる可能性があります。攻撃者は、その情報をもとにアプリを通さず、APIへ直接リクエストを送ることができます。
図1：NICTの発表を基に当社作成。概念図であり、NICTの図版の転載ではありません。画像を開くと拡大できます。
攻撃の流れは、大きく4段階です。
- 攻撃者が公開アプリを入手する
- アプリを解析し、APIの接続先や通信方法を調べる
- 対象のサーバに合わせた不正なリクエストを送る
- サーバ側に弱点があれば、情報の不正取得や改ざんにつながる
重要なのは、アプリ自体に不具合がなくても、接続先のサーバに弱点があれば被害が起こり得ることです。
なぜアプリを隠すだけでは守れないのか
一般利用者には見えないAPIや通信の仕組みでも、公開アプリに含まれるプログラムや通信内容を解析すれば、攻撃者に知られる可能性があります。
つまり、「画面にボタンを出していない」「APIのURLを公開していない」だけでは、十分な防御になりません。アプリは利用者の端末上で動くため、解析されることを完全に防ぐのは困難です。
守るべき場所は、アプリの裏側にあるサーバです。サーバはリクエストを受けるたびに、少なくとも次のことを確認する必要があります。
- 誰からのリクエストか
- その人に、この情報を見る権限があるか
- 入力された値は安全か
- 短時間に大量のアクセスが行われていないか
- 管理機能や検証環境が不要に公開されていないか
「アプリから送られてきたように見えるから信用する」という設計は危険です。攻撃者は、正規アプリと同じ形の通信を自分で作って送ることができるからです。
点検する4つの弱点
NICTのCYNEX概要ページは、次の弱点や設定不備を重点的な点検対象に挙げています。表の具体例は、それぞれの意味を説明するためのものです。
| 弱点 | かんたんな説明 | 起こり得ること |
|---|---|---|
| IDOR / BOLA（認可不備） | URLやリクエスト内の会員ID・注文IDを書き換えると、他人の情報まで見えてしまう | 個人情報の大量取得、他人のデータの変更 |
| SQLインジェクション | 入力欄などを通じて、データベースに想定外の命令を実行させる | 情報の不正取得、認証回避、データ改ざん |
| SSRF | サーバに、本来アクセスしてはいけない内部システムへ通信させる | 内部情報やクラウドの認証情報の取得 |
| RCE | 外部からサーバ上で不正な命令やプログラムを実行する | 情報窃取、改ざん、サーバの乗っ取り |
なかでもIDOR / BOLAは、仕組みを理解しておきたい問題です。
たとえば、利用者Aの注文履歴を表示するAPIに「注文番号1234」が送られるとします。サーバがログインの有無だけを確認し、「注文番号1234が本当に利用者Aの注文か」を確認していなければ、番号を書き換えるだけで別の利用者の注文が見えてしまう可能性があります。
ログインできたかを確認する「認証」と、その情報を見てよいかを確認する「認可」は別です。多要素認証でログインを強化しても、データごとの認可が抜けていれば、この問題は解決しません。
AIによって攻撃が速く、広くなる可能性
NICTは、AIの活用によってアプリの解析や脆弱性探索が効率化され、同様の攻撃がより多くのシステムへ広がる可能性にも注意を促しています。
ただし、ここは慎重に読む必要があります。NICTの発表は、「最近の情報漏えいがすべてAIによる自動攻撃だった」と断定するものではありません。また、国内で発生したすべての情報漏えいがA2B攻撃によるものだという意味でもありません。
企業規模だけで点検の要否を決めず、公開APIと扱うデータ、現在の認証・認可の実装を確認します。
企業が今すぐ確認すべき3つのこと
NICTが推奨する対応は、「侵害の確認」「脆弱性の点検」「暫定的な緩和策」の3つです。必ずこの順に完了させるという意味ではありません。被害が続いている疑いがあれば、証拠の保全と被害拡大の抑止を並行して判断します。以下の具体的な作業例は、これらを日常の運用に当てはめたものです。
図2：NICTのCYNEX概要ページを基に当社作成。3つの対応を示したもので、順番を固定するものではありません。画像を開くと拡大できます。
1．侵害の確認：すでに不正利用されていないか
まず、自社が公開しているAPIやサーバを洗い出します。現行サービスだけでなく、旧バージョンのAPI、サブドメイン、検証環境、クラウド上の公開サービスも対象です。
そのうえで、保存されているアクセスログ、APIログ、認証ログの期間と欠落を確認します。以下は調査項目の例です。ログがない期間については、侵害がなかったと結論づけず、確認できない範囲を記録します。
次のような動きがないかを確認します。
- 認証なしで大量の情報を取得しようとするアクセス
- 連続した会員IDや注文IDへのアクセス
- 他会員の情報の閲覧・変更
- 不審な認証トークンの発行
- 通常は使われない管理機能へのアクセス
2．脆弱性の点検：サーバが不正な要求を拒否できるか
公開APIやサーバに対して、認証・認可・入力値の検証が正しく行われているか確認します。正常な操作ができることだけでなく、権限のない利用者が操作しようとしたときに、拒否されることをテストします。検証用の利用者とデータを用意し、対象・実施権限・業務への影響を確認してから行ってください。
あわせて、クラウドストレージの公開設定、固定された認証情報や暗号鍵、不要な管理機能、ファイル操作やコード実行につながる弱点も確認します。
3．暫定的な緩和策：修正までの被害を抑える
問題が見つかった場合や、すぐに安全性を確認できない場合は、業務への影響を見ながら一時的な対策を行います。
- 不要なAPI、管理機能、検証環境を停止・制限する
- 必要に応じてアクセス元を制限する
- レート制限やWAFで大量・連続アクセスを抑える
- 漏えいのおそれがある認証情報やトークンを無効化・再発行する
- 重大な危険を抑えられない場合は、該当機能やサービスの一時停止を検討する
WAFやレート制限は、データごとの認可不備を修正する代わりにはなりません。暫定策で影響を抑えながら、原因を修正し、拒否すべき操作を再確認します。
IPアドレスなどのIoC（侵害指標）との一致・不一致だけで、侵害の有無を断定することはできません。ログや通信内容、実際にアクセスされたデータを組み合わせて判断する必要があります。
Androidアプリがなくても関係する
今回の注意喚起はAndroidアプリを起点としていますが、NICTは、同様の問題がiOSアプリやWebサービスのバックエンドAPIでも発生する可能性があるとしています。
そのため、次のような企業も点検対象です。
- スマートフォンアプリを提供している
- 会員サイトやECサイトを運営している
- SaaSとして顧客データを扱っている
- Web画面から呼び出すAPIがある
- 外部サービスや取引先向けにAPIを公開している
「Androidアプリを作っていないから関係ない」と考えず、外部から利用できるAPIと、その先にあるデータを確認することが大切です。
点検の準備状況を確認する5つの質問
次の表で分からない項目があれば、担当者と確認方法を決めます。回答だけで脆弱性や侵害の有無を判定できるものではありません。
| 確認すること | 「分からない」場合に考えられる問題 |
|---|---|
| 公開中のAPI、旧API、検証環境を一覧にできるか | 管理対象外の入口が残っている可能性がある |
| APIごとに、利用者と権限の確認方法を説明できるか | 認証後の認可不備を見落としている可能性がある |
| アクセスログ・APIログ・認証ログの保存期間が決まっているか | 過去の不審アクセスを調査できない可能性がある |
| 大量取得や連番IDへのアクセスを検知できるか | 情報取得が続いても気づけない可能性がある |
| 問題発見時の停止判断者、連絡先、修正担当が決まっているか | 初動が遅れ、被害が拡大する可能性がある |
APIの変更後も点検を続ける
A2B攻撃への対応は、一度だけ脆弱性診断を実施すれば終わるものではありません。
サービスは更新され、APIは増え、クラウドの設定も変わります。担当者の異動や委託先の変更によって、存在が把握されていない旧APIや検証環境が残ることもあります。ログを保存していても、誰も確認していなければ異常の発見は遅れます。
必要なのは、次の流れを継続的な運用として回すことです。
- 公開しているシステムとAPIを把握する
- 権限・設定・脆弱性を定期的に点検する
- ログを取得し、異常な使われ方を監視する
- 問題を見つけたときの判断・連絡・修正手順を決める
- 変更後も安全性を確認し、記録を残す
APIを追加・変更するときは、権限のテストとログの記録項目を確認します。担当者や委託先が変わるときは、通知先と対応手順を更新してください。専門的な診断と日常の運用点検は、必要な範囲を分けて組み合わせます。
AWS運用全体については、専任の運用担当がいないSaaS企業へ｜AWS運用で確認する5項目でも、構成、権限、復旧、監視後の対応、リリースの観点から整理しています。APIの点検だけでなく、本番運用全体を確認する際にあわせてご覧ください。
まとめ
A2B攻撃で最も重要な教訓は、公開アプリやWeb画面の裏側は、攻撃者にも調べられるということです。
アプリの解析そのものを完全に防ぐのではなく、APIの仕様を知られ、直接操作されたとしても、サーバ側で不正なアクセスを拒否できる状態をつくる必要があります。
まずは、次の3点から確認してみてください。
- 自社が公開しているAPIとサーバを一覧にできるか
- 誰が、どのログを、どの頻度で確認するか決まっているか
- 他人・他社のデータにアクセスできないことをテストしているか
一つでも答えが曖昧であれば、公開範囲とログ取得状況の棚卸しから始めることをおすすめします。
公開API・クラウド運用の見直しについて相談する
公開範囲やログの保存先が分からず確認が進まない場合は、現在の状況をお知らせください。クラウド環境の調査、手順の整備、移行・運用支援などの対応可否を個別に確認します。専門的な脆弱性診断や侵害調査についても、対応できる範囲を確認したうえでご案内します。
「公開APIやクラウド環境の全体像を把握できていない」「専任担当者を置けず、点検が後回しになっている」といった課題がある場合は、まず現状の棚卸しからご相談ください。相談時点ですべての構成資料が揃っている必要はありません。
お問い合わせの際に、次の3点を分かる範囲で記載いただくと、確認対象を整理できます。
- 現在困っていること、確認したいこと
- 現在の開発・運用・セキュリティ担当体制
- 点検や改善を行いたい時期
対応可否、調査範囲、実施方法、費用は、現在の構成とご要望を確認して個別にご案内します。
参考資料
参考資料の確認日：2026年10月15日。NICTの公表内容と、企業の運用に当てはめた確認例を掲載しています。個別システムの安全性は、構成や運用状況に応じた確認が必要です。
