APIのURLが分かっただけで、なぜ個人情報が漏れるのか

最近、Androidアプリを解析してAPIを突き止める攻撃が話題になっています。AIを使った攻撃として紹介されることもあります。

報告を読んでいて、どうも引っかかりました。APIの場所が分かっただけで個人情報が漏れるとしたら、それは攻撃手法の高度さより、サービスを作った側の問題ではないでしょうか。

人が集まる正面玄関には、立派な鍵を付け、入館証ゲートまで置いている。そこには随分お金をかけたのに、建物の裏の通用口には鍵もゲートもない。

これまでは通用口を見つけるのが面倒だった。ところがAIを使えば、怪しい入口をしつこく探して、次々に試せる。やっと通用口を見つけたと思ったら、普通に入れてしまった。

そんな建物があったら、まず「なぜ裏口に鍵がないのか」と思うはずです。

アプリを調べればAPIは見つかる

NICTは2026年10月13日、Androidアプリの解析を起点にバックエンドを狙う「A2B攻撃（App-to-Backend Attack）」について発表しました。JPCERT/CCも10月15日、APKの解析によってAPIを特定する攻撃手法を取り上げています。

そもそもAndroidアプリは、利用者に配布するプログラムです。サーバーと通信するための情報がアプリ内にあれば、解析して調べることはできます。AIがその作業を速めることもあるでしょう。

ただ、URLが分かるのと、そのAPIを使う権限があるのとは違います。

アプリの画面ではログイン後にしか表示されない情報でも、裏側のAPIは画面を経由せず直接呼び出せます。ログイン画面を用意しただけで、APIまで守られるわけではありません。API自身が、呼び出した相手を確認する必要があります。

もし未ログインの相手に個人情報を返してしまうなら、認証の実装を疑うことになります。まさに鍵のない通用口です。

さらに、ログインは正しく動いているのに情報が漏れることもあります。

例えば、注文履歴を表示するAPIがあるとします。利用者が自分の注文を見られるのは当然です。ところが、リクエストの注文IDを他人のものに変えただけで、その注文まで表示されたらどうでしょう。

サーバーは「ログイン済みか」は調べていても、「この注文を見てよい人か」は調べていません。

OWASPがAPI Security Top 10 2023の第1項目に挙げるBOLA（Broken Object Level Authorization）は、このようなオブジェクト単位の認可不備です。IDを差し替えて他人のデータを取得できる問題は、IDOR（Insecure Direct Object Reference）としても知られています。

入館証は持っている。しかし、他人の部屋の扉まで開いてしまう。BOLAはそういう話です。注文IDを推測しにくい文字列に変えたところで、本人の注文かどうかを確認しなければ直りません。

いずれもAIが登場する前から知られていた問題です。設計段階で権限の確認を考えていなかったのか、考えていたのに実装が抜けたのか。理由はさまざまでしょうが、APIを見つけられたこと自体が原因ではありません。

IPAは10月9日の注意喚起で、公開アプリケーションやAPI連携を含む構成要素の管理、権限の見直しを促しています。JPCERT/CCもAPIのアクセス制御に注意を向けています。

未ログインで呼び出したらどうなるか。ログイン済みの一般ユーザーが別の顧客のIDを指定したらどうなるか。管理者だけが使える機能を一般ユーザーが呼び出したらどうなるか。

それをすべてのAPIで漏れなく実装し、確かめなければなりません。画面から操作できない機能でも、APIが残っていれば呼び出されます。通常の画面操作が成功したというテストでは、権限のないリクエストを拒否できるかは分かりません。

AIによって、これまで見つかりにくかった通用口が見つかるようになる。攻撃者の探索が速くなるのは厄介です。けれども、だからといって通用口に鍵を付けなくてよい理由にはなりません。

AIによる攻撃の巧妙さを語る前に、アプリケーションのセキュリティ設計や実装に問題がなかったのかを調べるべきでしょう。

正面玄関にいくらお金をかけても、裏の通用口が開いていたら意味がありません。