目次
会員画面には管理ボタンがない。それでも、その裏のAPIが一般利用者から呼べないとは限りません。AIによる開発や自動連携が広がる今こそ、画面の見た目とサーバーの許可条件を分けて点検する必要があります。
JPCERT/CCは2026年10月8日、国内組織で相次ぐ不正アクセスについて注意喚起を公開し、10月9日に更新しました。情報確認日は10月15日です。文書が扱う被害の時期は主に2026年9月前後であり、注意喚起の公開日に一斉に事件が起きたという意味ではありません。
スポンサーリンク
確認された事実と、まだ分からないこと
同注意喚起のケースBは、管理用APIへの不正な要求による情報の書き換えなどを扱っています。画面ではできない権限変更やアカウント作成、別システムから窃取されたAPIキーの利用などが報告されています。一つの共通原因で全事案を説明する文書ではありません。 根拠資料：JPCERT/CC：国内組織における不正アクセスの注意喚起（2026年10月8日公開・9日更新）。
JPCERT/CC自身、把握している技術情報は限定的・断片的だとしています。本記事も、個別の被害企業の侵入経路や攻撃者を推定しません。注意喚起を根拠に、生成AIによる自律攻撃だったと断定することもできません。以下の構成例と点検順序は、本サイトからの提案です。
ログインできることと、操作してよいことは違う
認証は利用者が誰かを確認する処理、認可はその利用者に何を許すかを決める処理です。有効なトークンを持つ一般会員でも、他人の注文を見たり、管理者を追加したりできてよいわけではありません。認証成功の後にも、業務ごとの判断が残ります。
OWASPのAPI1は、操作対象ごとの認可不備を扱っています。例えば、自分の契約を取得するAPIで、対象IDを変えて他社の契約を読める状態です。IDを長い乱数にするだけでは、漏れたIDや別の画面から知ったIDへのアクセス権は判定できません。 根拠資料：OWASP：API1:2023 Broken Object Level Authorization。
API5は、管理機能などの実行権限の不備を扱います。注文の閲覧を許可したからといって、一括出力や強制取消まで許可したことにはなりません。対象の所有者、実行する機能、変更可能な項目という三つの観点を、レビュー時に別々に確認すると漏れを見つけやすくなります。 根拠資料：OWASP：API5:2023 Broken Function Level Authorization。
スポンサーリンク
最初に作るのは、画面一覧ではなくAPI台帳
本サイトでは、外部へ公開しているAPIと、内部専用と考えているAPIを同じ台帳へ載せる方法を提案します。URL、HTTPメソッド、実行内容、所有部署、利用する認証、許可対象、扱うデータ、廃止予定を記録します。古いバージョンやモバイルアプリ専用の経路も含めます。
「内部」という名前のパスでも、インターネットから到達できるなら入口です。WordPressでは独自RESTルート、プラグインのAjax処理、外部連携用の受信口などを開発担当者と確認します。REST API全体を閉じるか開くかだけの二択では、残す機能の権限設計が見えません。
レンタルサーバーの管理権限がなくても、制作会社やプラグイン提供元へ台帳の項目を照会できます。担当者不明のAPIは、そのまま恒久運用する理由にはなりません。利用実態を調べ、必要なものは担当を決め、不要なものは影響確認を経て停止します。
操作・対象・変更項目を一組として許可する
説明用に、会員サイトのプロフィール更新を考えます。本人の表示名を変える権限があっても、同じ要求に会員ランクや管理権限の値を混ぜて変更できる設計は危険です。受信したJSONの全項目を、そのまま利用者レコードへ保存しないことを提案します。
サーバーは認証済みの利用者を起点に対象を確認し、その操作に必要な権限を検査し、更新を許す項目だけを選びます。拒否を基本にして、明示した条件でのみ許可します。ブラウザーの非表示項目や、AIが生成した「管理者です」という説明を、権限の根拠にしません。
AIエージェントを連携する場合も同様です。「AIだから広い権限が必要」と考える前に、読む、下書きを作る、公開する、削除するを分けます。本記事の主題はAPI側の認可であり、モデルの回答品質を改善しても、この検査が不要になるわけではありません。
スポンサーリンク
レート制限とアクセス制御は役割が異なる
JPCERT/CCはAPIごとのアクセス制御に加え、負荷や悪用のリスクが高い機能への個別制限、トークンの権限縮小・有効期限・無効化を勧めています。大量実行を止める制限があっても、一回の要求で他人の情報を読めるなら、認可の問題は残ります。 根拠資料：OWASP：REST Security Cheat Sheet。
逆に、正しい権限の利用者による検索や一括取得でも、無制限な反復はサービスを圧迫します。ログイン、パスワードリセット、検索、エクスポートを同じ回数制限にまとめず、通常の利用方法を測って設定します。数値は全サイト共通の値ではなく、機能と業務に応じて決めます。
運営者向けの管理APIは、必要に応じてネットワークの到達範囲も絞ります。ただし、IP制限だけを本人確認や対象ごとの権限の代わりにはしません。委託先の回線変更や運用担当者の交代時も、誰の操作かを追える認証を保つことが必要です。
安全な点検は「拒否されるケース」も作る
検証用の会員A、会員B、管理者を用意し、架空の注文や資料で確認します。Aが自分の情報を読めるだけでは合格になりません。Bの対象ID、管理機能、許可外の変更項目、失効した資格情報でも、保存や取得が行われないことを確かめます。
HTTPメソッドが違う要求や、必須項目の欠落にも注意します。見慣れない形式で認証が失敗したときに、例外処理が権限検査を飛ばしていないかを確認してください。詳細な認証エラーを外部へ出しすぎない一方、内部ログには拒否理由と追跡用IDを残します。
- 機能の検査：一般会員による管理者追加、一括取得、強制変更を拒否する。
- 対象の検査：別会員・別顧客のレコードを指定しても、内容や件数を漏らさない。
- 項目の検査：許可した表示名だけを更新し、権限や所属の変更を受け付けない。
- 状態の検査：退会・権限取消・トークン失効後に、以前の許可が残らない。
テストは自社で許可された環境で実施します。本番の個人情報を確認用データとして複製せず、実在しない内容を使います。不正な要求への画面表示だけでなく、データベース、送信処理、監査ログに副作用がないかまで確認します。
不審な痕跡があるときは、修正前に記録を確保する
急に不明な管理者が増えた、権限変更が続く、通常使わないAPIの呼び出しが増えた場合は、担当者へ連絡し、必要なログを保全します。アクセス制限やトークン失効で影響を抑える作業と、調査に必要な記録の確保を並行できるよう、平時から役割を決めておきます。
注意喚起にある過去のIPアドレスやUser-Agentだけで、現在の通信を攻撃と断定しないでください。正規利用と重なる可能性があり、攻撃側が値を変えることもあります。利用者、操作対象、権限変更、発生時刻を組み合わせて評価する必要があります。
侵害の疑いがある状態では、認可処理を直して画面が動いたことだけで対応を終えません。不明なアカウント、追加された資格情報、公開範囲の変更などを調べ、必要に応じてホスティング事業者や対応支援者へ相談します。削除されたログを後から取り戻せるとは限りません。
一覧取得と一件取得で、許可条件をそろえる
個別の詳細APIは正しく拒否していても、検索や一覧の応答へ権限外のタイトル、件数、連絡先が混ざる場合があります。本サイトでは、取得対象を絞る処理が一覧・検索・詳細・出力で共通の条件に従うかを確認することを提案します。画面に表示しない項目も、応答本文へ含まれていれば取得された情報です。
例えば、顧客Aの担当者で検索し、Bの案件が一覧の件数へ入らないか、CSV出力へ混ざらないか、ページ送りで条件が外れないかを検証します。詳細画面だけを閉じて一覧へ全データを返す設計では、十分な分離にはなりません。逆に、権限不足と対象不存在の応答の差から、非公開の存在が分かる可能性も評価します。
スポンサーリンク
APIを廃止したつもりの経路も確認する
新しい版へ移行した後に古いURLや別メソッドが残っていないかを調べます。利用ログ、ルーティング設定、モバイルアプリ、定期処理を照合し、実際に必要な経路を確定します。古い仕様書に廃止と書いたことと、サーバーが要求を拒否することは別です。
停止するときは、正規利用への影響と代替経路を確認し、変更後の応答と監視を検証します。使う担当者が分からないからという理由で、強い権限のAPIを放置しないことが重要です。所有者、廃止判断、確認日を台帳へ残せば、次の点検でも同じ調査を繰り返さずに済みます。
今日の運用へ落とし込むなら
最初の一歩は、管理機能と個人情報の取得機能を優先した棚卸しです。次に、許可の条件と拒否テストを対応させ、最後に失効と異常検知の手順を確かめます。すべてを一度に作り直すより、責任者と合格条件が分かる単位で改善すると継続できます。
WAFやAIによるレビューも補助にはなりますが、業務上の「誰が誰の何を変更できるか」は運営側で定義する必要があります。今回の注意喚起を、特定の攻撃名を追うだけで終わらせず、サーバーの許可条件を説明できる状態へつなげましょう。
スポンサーリンク
