【内部APIのアクセス制御は誰が守るのか】 2026年秋の情報漏えいから学ぶWebセキュリティ

2026年11月4日

2026年秋、国内で情報漏えいの公表が相次ぎました。原因はひとつではなく、業種も手口もばらばらです。ただ、公表された内容を並べて読んでいくと、共通して見えてくるものがあります。攻撃者が最初に触っていたのは、外側の壁ではなく、すでに内側につながっていた経路でした。

攻撃の入口は、公開アプリとアカウント

2026年10月8日、JPCERT/CC（※1）は国内組織で相次ぐ不正アクセスについて注意喚起を公表しました。対象は2026年9月前後から続く事案で、同センターは「技術的な情報の共有が不足しており、把握している情報は限定的かつ断片的」としつつ、確認されている攻撃手法と痕跡を4つのケースに整理しています。

翌9日にはIPA（※2）が、大量の個人情報を取り扱う事業者に向けて点検と対策を呼びかけました。ここで押さえておきたいのは、IPAが「現段階では、特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず」としたうえで、公表事例の傾向から「外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっている」と見ている点です。

狙われたのは、特定の製品の弱点というより、公開しているアプリと、そこにログインするためのアカウントでした。

（※1）https://www.jpcert.or.jp/at/2026/at260030.html

（※2）https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html

画面からは呼べない内部APIが、狙われている

JPCERT/CCが挙げた4つのケースのうち、Web開発に直結するのが「ケースB：API経由での不正な操作」です。報告されている手口は具体的です。まず一般公開されているスマートフォンアプリを解析し、APIのエンドポイントやキーを特定する。次に、本来は画面操作では実行できない内部APIに対して、ユーザー権限の変更や不正なアカウントの作成を試みる。ヘッダーの有無や不正な形式の認証トークンを付けて応答の違いを確認したり、NoSQLインジェクションによる探索でアカウント情報を特定したりする。さらには、他のシステムの侵害で窃取したAPIキーを使う、という流れです。

ここで効いてくるのが「本来は画面操作では実行できない」という一言です。例えば、画面にボタンがなければ安全、という前提は成り立ちません。同じ時期、個人情報保護委員会が改訂した注意喚起（WARNING）でも、漏えい事案が9つの事例に類型化され、そのひとつに「APIが悪用される事例」が追加されています。ログイン後にパラメータを書き換えると、本来は見えないはずの他ユーザーの情報を取得できてしまう状態だった、というものです。

なお、JPCERT/CCは「すべての事案で同一の攻撃手法が使用されていることを示すものではありません」と限定しています。手口を断定せずに読む姿勢も、ここでは大切です。

アクセス制御は、画面ではなくAPIの単位でかける

では、実装側では何を見直せばよいのでしょうか。まず前提として、認証とアクセス制御は別の役割です。認証は「あなたは誰か」を確かめること。アクセス制御は「その人が何をしてよいか」を判断することです。ログインできたかどうかと、その操作を許してよいかどうかは、別々に確認しなければなりません。

例えば、他ユーザーの情報を編集する機能があったとします。権限のない人に画面のボタンを出さない設計は親切ですが、それだけでは守れません。ボタンがなくても、HTMLやアプリの中身を見ればリクエストの形は分かります。だからこそ、サーバー側でエンドポイントごと、HTTPメソッドごとに「誰が何をできるか」を判断する必要があります。

IPAも、対策として「外部公開範囲の見直し」「アカウントへの権限付与の見直し」「API連携等アプリケーション構成要素単位での管理状況の見直し」を挙げています。

この考え方は、実は新しいものではありません。徳丸浩氏は2026年9月のインタビュー記事（※3）で「12年前と比べて、対策の基本は変わっていませんよ」と語っています。攻撃の速さや量は変わっても、見るべき場所は変わっていないのです。

（※3）https://webtan.impress.co.jp/e/2026/09/02/53179