相次ぐ個人情報漏えい、実はAPI認可テストが鍵かも

2026 10/06

2026年10月6日 2026年10月6日

AIが攻撃に使われ始めた、というニュースが続いています。2026年9月、セキュリティ企業Gambit Securityは、金銭目的の攻撃者がオープンソースのAIエージェントを組み合わせてECサイトを狙った事例を報告しました。ほぼ同じ時期に、国内でも通販や物流などのサービスで不正アクセスが相次いで公表されています。

こうした報道を見ると「高度な攻撃だから自社には関係ない」と感じるかもしれません。けれど、実際に突かれているのは、もっと地味な場所である可能性が高いと考えられます。その代表がAPI認可の不備——ログインした利用者が、本来見えてはいけない他人のデータにアクセスできてしまう、という穴です。

この記事では、Webアプリ・スマホアプリを発注する側の担当者・決裁者に向けて、いま何が起きているのか、なぜ機能テストだけでは防げないのか、そして発注側が今日からできるAPI認可テストの備えを整理します。攻撃の手口そのものではなく、「どんな不備があり、何を確認すべきか」に絞ってお伝えします。

いま何が起きているか

AIエージェントが攻撃に使われ始めた

Gambit Securityの報告（2026年9月）によると、金銭目的の攻撃者が、公開されているAIエージェント3種を役割分担させてECサイトを攻撃しました。1つが脆弱性（ぜいじゃくせい＝攻撃に使われ得る弱点）の探索、1つが侵入、1つが全体の統括という形です。

報告された事実を、煽らずに要点だけ挙げます。

2026年9月10〜15日に105件の攻撃プロジェクトが実行され、少なくとも27社が侵入された
60万件を超えるカード情報が流出したが、これは27社全体ではなく「2社から」のもの
19社で、決済画面にカード情報を盗むスクリプトが仕込まれていた
標的探し（スキャン）のAI利用料は、1社あたり平均で約25ドル
完全な自動ではなく、人が短い指示を出し、探索の多くをAIに任せる形だった

注目したいのは最後の2点です。これは「AIが勝手に攻撃する」話ではありません。攻撃者が標的を探すコストが大きく下がった、という話です。これまで手間がかかって見送られていた中小規模のサイトも、攻撃者にとって割に合う標的になりつつあります。

なお、今回使われたツールの一部は、本来は正規のテスト用（攻撃を模擬して自社の守りを点検する用途）に作られたものです。道具は、攻める側も守る側も同じものを使えます。

国内でも不正アクセスが相次いでいる

2026年9月下旬には、国内の通販・物流など複数のサービスで不正アクセスが公表されました。原因は各社が調査中であり、ここで特定の企業について原因を断定したり推測したりすることはしません。

ただ一般論として、正規の経路（アプリやAPI）を通って、本来アクセスできないはずのデータを読まれるという不備は、どのサービスでも起こり得ます。サーバーに無理やり侵入しなくても、アプリの入り口から「正しい手順で」データを引き出せてしまうケースです。こうした一連の事案でも、API認可の不備が背景にある可能性は高いと考えられますが、個別の原因については各社の調査結果を待つ必要があります。

なぜアプリ（API）が狙われるのか

APIとは、アプリとサーバーがデータをやり取りする窓口のことです。スマホアプリで「注文履歴」を開くと、裏側ではアプリがAPIに「この利用者の注文を見せて」と問い合わせています。

攻撃者から見ると、サーバーそのものに侵入するより、この窓口の確認漏れを突くほうが安く、速く済みます。

サーバーへの侵入は手間がかかり、痕跡も残りやすい
一方、APIの「誰の・どのデータを返してよいか」の確認が甘ければ、正規の通信を少し変えるだけで済む

先ほどの「標的探しのコストが下がった」という流れと重ねると、結論はシンプルです。確認が甘いAPIを持つサイトは、狙われる確率が上がっていると考えられます。

よくあるAPI認可の不備3つ

技術的な手順には踏み込まず、「どんな不備か」を日常の言葉で説明します。いずれも、エンジニアでなくてもイメージできる例を添えます。

(1) 他人のIDを指定すると、その人のデータが見えてしまう

いわゆる BOLA（他人のIDを指定すると、その人のデータが見えてしまう不備）です。

例：注文履歴ページのURLの末尾が「id=1001」のとき、「1002」に変えると他人の注文履歴が表示されてしまう
本来は「それはあなたの注文ではありません」と断るべきところを、確認を省いて返してしまう

(2) 権限チェックの漏れ

一般の利用者が、本来は管理者しか使えない機能を呼び出せてしまう不備です。

例：画面に「編集」ボタンが表示されていなくても、その機能を直接呼び出せてしまい、他人の情報を書き換えられる
「画面に出していない＝使えない」ではない、という点が見落とされがちです

(3) 必要以上のデータを返している

画面には一部しか表示していないのに、裏側では余計な情報まで返してしまう不備です。

例：会員一覧画面には名前しか出ていないのに、APIの応答にはメールアドレスや電話番号まで含まれている
攻撃者は、その「画面には見えていないが返ってきている」情報を拾います

これら3つに共通するのは、画面上はどれも正常に見える、という点です。だからこそ、次の「機能テスト」との相性が問題になります。

なぜ機能テストでは見つからないのか

機能テストは、「仕様どおりに正しく動くか」を確認するものです。たとえば次のような確認です。

ログインできる
自分の注文履歴が表示される
注文を確定できる

これらはすべて「正しい利用者が、正しい操作をしたとき」の確認です。とても大切ですが、「悪意のある人が、正しくない操作をしたとき」は想定していません。両者の違いを並べると分かりやすくなります。

観点	機能テストの確認	認可の観点での確認
自分の注文（id=1001）	見られる（OK）	見られる（OK）
他人の注文（id=1002）	確認しない	見えてはいけない
管理者機能の直接呼び出し	確認しない	拒否されるべき
応答に含まれる項目	画面表示だけ確認	余計な情報を返さない

機能テストに合格していても、右側の列を確認していなければ、先ほどの不備はすり抜けます。機能テストの合格と、情報が漏れないことは、別の話です。

発注側が今日からできること

専門のセキュリティ診断をすぐに手配しなくても、やれることがあります。発注側がテスト計画にAPI認可テストの観点を加えるだけで、見つかる不備は大きく変わります。

「仕様書が整っていないから」「短納期だから」と諦める必要はありません。仕様書がなくても、実際の画面とデータの動きを見ながらテスト設計を起こすことはできます。みんなシステムズでは、そうした案件にも対応しています。

テスト計画に入れたいAPI認可テストの観点チェックリスト

発注の打ち合わせで、次の観点が確認される計画になっているかを問いかけてみてください。エンジニアでなくても「これは確認されていますか？」と聞ける粒度にしています。

ログイン中の利用者が、他人のIDを指定して他人のデータを取得できないか（BOLA）
ログインしていない状態で、本来保護されたデータにアクセスできないか
一般利用者が、管理者向けの機能を直接呼び出せないか（権限チェック）
画面に表示していない余計な情報まで、裏側で返していないか
ID・金額・件数などの値を書き換えたとき、適切に拒否されるか
退会や権限変更のあと、古い権限のまま引き続きアクセスできないか
これらの観点が、機能テストとは別枠でテスト項目に入っているか

この7項目を発注時に一度確認するだけでも、抜けに気づけることがあります。より詳しい観点は、権限・ロールのテスト観点をまとめた記事や、APIテストのやり方と確認観点の記事も参考にしてください。

まとめ

AIによって、攻撃者が標的を探すコストが下がった。確認の甘いAPIは狙われやすくなっていると考えられる
狙われやすいのは高度な侵入よりも、API認可の不備である可能性が高い（他人のデータが見えてしまう等）
これらは画面上は正常に見えるため、機能テストだけではすり抜ける
発注側は、テスト計画に認可の観点を加えるだけで、備えを一段上げられる

みんなシステムズのテスト代行は、機能テストに加えてセキュリティの観点（認可の確認など）を組み込んだテスト設計に対応しています。仕様書が整っていない案件でも、画面とデータの動きからテスト設計を起こせます。テスト代行サービスの詳細はこちらでご確認ください。外部に任せる場合の進め方は、脆弱性診断の外注で押さえる依頼範囲の記事もあわせてご覧ください。

出典・参考