何が起きるか
認可は、サーバーが利用者・対象データ・操作の組み合わせを確認して、許可するか決める処理です。認可の不備では、本人としてログインできることだけを理由に、その人が読めない他人のデータまで返したり、許されていない更新まで保存したりします。
説明用の例では、攻撃者が自分のアカウントでログインし、注文表示APIへ送るURLの注文番号を、自分の注文から他人の注文へ差し替えます。APIはCookie内のセッションIDからログイン利用者を特定します。しかしログインと注文の存在だけを確認し、注文の所有者と利用者を照合しなければ、他人の注文の配送先を攻撃者へ返してしまいます。IDORは、入力されたIDが指すデータを、その利用者が操作してよいか検査しない不備です。攻撃には対象のIDを知る・推測するなどして指定できることが必要です。
正常ならどう動くか
注文の詳細APIでは、サーバーがCookie内のセッションIDをサーバーに保存した利用者情報と照合し、ログイン利用者を特定します。その上で、URLで指定された注文IDと、その注文に保存された所有者IDを調べます。
本人の注文だけを見せる構成なら、注文IDとログイン利用者のIDの両方を検索条件に入れます。注文が存在しても所有者が違えば検索結果には入らず、サーバーは注文内容を応答へ入れません。この例の管理者向け機能などに例外が必要なら、別途明示した権限の検査で許可します。
不備と攻撃が成立する流れ
攻撃者は自分の注文を表示するときのHTTPリクエストを調べ、URLや本文にある注文IDを、入手または推測した他人の注文IDへ差し替えて送信します。APIがCookieでログインを確認し、指定した注文が存在すれば返すだけの実装だと、所有者が違っても他人の注文を返してしまいます。サーバーがIDと所有者の関係を検査していないことが不備です。
権限付与APIでは、攻撃者が自分のアカウントを編集できることと、管理者という役割を付与できることを分けて検査する必要があります。APIが編集権限だけを検査し、送られたグループIDをそのまま保存する実装なら、攻撃者は自分のユーザーIDと管理者グループのIDを送って管理者に昇格できるおそれがあります。この例ではユーザーに所属グループのIDを保存し、そのグループに与えた役割で操作権限を決めます。次のリクエストでサーバーがそのユーザーのグループIDから管理者という役割を取得すると、管理機能まで許可してしまいます。
起こり得る被害と条件
読み取りの例では、他人の注文に含まれる氏名・配送先がAPIのHTTPレスポンスに入り、攻撃者の端末へ届きます。自分のアカウントでは本来読めない個人情報を入手することが攻撃の目的です。
更新の例では、攻撃者が他人の注文IDと変更後の配送先を更新APIへ送ります。所有者の認可がなければ、他人の注文の配送先を攻撃者が変更できるおそれがあります。注文の状態などによる変更制限があれば、その条件も関係します。
権限昇格の例では、自分への管理者権限の付与が保存されると、次のリクエストで管理機能を使用できるようになります。対象を指定できることに加え、サーバーの権限検査がその操作を誤って許可することが成立条件です。
防ぎ方と、防げる理由
利用者・対象・操作・所属組織をサーバー側の情報と照合し、許可できた場合だけデータを返す・更新するようにします。注文なら、下の説明用コードのように注文IDとセッションから得た所有者IDを同時に検索条件へ入れます。条件に合う注文がなければ、他人のデータを返す前に拒否できます。コード中のsession.userIdは、リクエスト本文で申告された値ではなく、認証済みのセッションから得たIDです。
権限付与では、対象ユーザーを編集できるかに加え、付与しようとする役割まで許されているか確認します。一括更新やエクスポートでも、含まれるデータと操作ごとに同じ認可を行います。通常の詳細APIだけで所有者を検査しても、エクスポートがIDだけで全件を返せば、攻撃者はそちらから他人の情報を取得できるためです。
説明用の擬似コード（実際の製品コードではありません）
// 危険: IDの存在しか確認しない
const order = await db.orders.findById(id);
// 修正: 読める集合へ検索条件を限定
const order = await db.orders.findOne({ id, ownerId: session.userId });
if (!order) throw new ForbiddenError();よくある誤解
ボタンを隠してもAPIは直接呼べます。推測しにくいUUIDを使っても、共有リンクなどからIDが分かれば操作され得ます。画面の表示制御やIDの秘密性を、サーバーの認可の代わりにしてはいけません。
実装の確認点
詳細取得・一覧・一括更新・エクスポートで同じデータを扱うAPIを列挙します。それぞれに、自分と他人、同じ組織と別組織、一般利用者と管理者の組み合わせを当てはめます。APIが認証済みというだけで応答せず、対象のデータと操作内容まで許可条件を検査しているか確認します。
出典・確認範囲
- [1] Web Security Academy: 認可の不備・IDORPortSwigger / 確認日 2026-11-01