概要

IDOR（Insecure Direct Object Reference、安全でない直接オブジェクト参照）は、URLやリクエストパラメータに含まれるオブジェクトID（注文番号・ファイルID・ユーザIDなど）をユーザが直接操作することで、認可チェックの欠落により他者のデータへアクセス・改ざんできてしまう脆弱性です。OWASP API Security Top 10では「BOLA（Broken Object Level Authorization）」として第1位に位置づけられており、実装ミスとして非常に発生しやすいためSC試験でも重要な出題領域です。本記事では認可バグの分類と具体的な攻撃手口を掘り下げます。

仕組みと動作原理

基本的な攻撃例

正規ユーザ（自分のID: 1001）のリクエスト：
GET /api/invoices/1001  → 自分の請求書（正常に表示される）

攻撃者がIDを書き換える：
GET /api/invoices/1002  → 他人の請求書がそのまま返ってくる（IDOR成立）

サーバが「認証されているか」だけを確認し、「そのリソースの所有者が本当に本人か」を確認していないために起こります。認証（Authentication）は通過しているが認可（Authorization）が欠落しているという点が本質です。

IDOR攻撃の基本的な流れ
1
攻撃者
正規の認証情報でログイン
自分のアカウントとしては正当
 2
攻撃者
リクエスト中のオブジェクトIDを書き換え
例: /invoices/1001 → /invoices/1002
 3
サーバ
認証済みであることのみ確認し処理
所有者チェックの欠落
 4
攻撃者
他人のリソースを取得・改ざん
IDOR（BOLA）の成立

認可バグの分類

IDORは「認可の不備」という大きなカテゴリの中の一パターンです。試験対策としては以下の分類を区別できることが重要です。

分類内容具体例
水平権限昇格（Horizontal Privilege Escalation）同じ権限レベルの他ユーザのデータにアクセス一般ユーザAが一般ユーザBの注文情報を閲覧
垂直権限昇格（Vertical Privilege Escalation）より高い権限レベルの機能・データにアクセス一般ユーザが管理者専用APIを呼び出す
BOLA（Broken Object Level Authorization）個々のオブジェクト（レコード）単位の所有者チェック欠落/api/orders/{id} のID書き換えで他人の注文にアクセス
BFLA（Broken Function Level Authorization）機能（エンドポイント）単位の権限チェック欠落DELETE /api/admin/users/{id} を一般ユーザが実行できる
マスアサインメントリクエストボディの余分なフィールドがそのままDB更新に使われる{"role": "admin"} を注文更新APIに紛れ込ませて権限を書き換え
水平権限昇格 と 垂直権限昇格 の比較
水平権限昇格 垂直権限昇格
権限レベルの変化
同レベルの他人のデータへ横移動
より高い権限へ上方移動
典型例
他ユーザの注文・請求書・個人情報の閲覧
一般ユーザが管理者機能を実行
悪用されるバグ分類
BOLA（オブジェクトレベル認可の不備）
BFLA（機能レベル認可の不備）
被害の範囲
個々のレコード単位（漏洩は同レベルに限定）
システム全体（管理機能を含む重大な被害）

IDORが成立しやすい実装パターン

  • 連番・推測可能なID：id=1001, id=1002 のような連番はIDを総当りされやすい
  • フロントエンドのみでの権限制御：ボタンの非表示だけで、APIリクエスト自体は防いでいない
  • クライアントから送られたロール情報の信用：リクエストボディの role や userId をそのまま信用してしまう
  • パラメータの型・場所（URL・ヘッダ・Cookie・JSONボディ）を横断した認可漏れ：一部の入力経路だけチェックが実装され、別経路が抜け漏れる

対策

1. サーバサイドでの所有者確認（根本対策）

# 脆弱：IDだけで検索してそのまま返す
invoice = db.get_invoice(request.params["id"])
return invoice

# 安全：ログイン中のユーザが所有者かを必ず確認
invoice = db.get_invoice(request.params["id"])
if invoice.owner_id != current_user.id:
    raise Forbidden()
return invoice

2. 間接参照（Indirect Object Reference）

推測可能な連番の代わりに、UUID等のランダムかつ推測困難な識別子を使う、またはユーザごとのマッピングテーブルを介して内部IDを直接露出しないようにします。ただし、間接参照は「推測されにくくする」対策であり、サーバサイドの所有者チェックを代替するものではない点に注意が必要です。

3. その他の対策

対策説明
ロールベースアクセス制御（RBAC）の一貫適用すべてのエンドポイントで統一的に認可チェックを実施
許可リスト方式のフィールド更新マスアサインメント対策として更新可能フィールドを明示的に限定
APIごとの認可テスト自動化他ユーザのIDでのアクセスを試すテストをCI/CDに組み込む
ログ監視・異常検知短時間での連番アクセス試行を検知してアラート

SC試験での頻出ポイント

  • 認証と認可の違い：IDORは「認証は通過しているが認可が欠落している」典型例として出題される
  • BOLAがOWASP API Top 10の1位：オブジェクトIDの推測しやすさと所有者チェックの欠落が主原因
  • 水平権限昇格と垂直権限昇格の区別：同レベルの他人データへの横移動か、より高い権限への昇格かを見分ける
  • 間接参照は根本対策ではない：推測困難なIDにしても、所有者チェックを省略してはならない
  • マスアサインメントとの関連：IDOR対策とあわせて、更新可能フィールドの許可リスト化が問われる

よくある誤問・ひっかけパターン

誤り① 「IDをUUIDのようなランダムな値にすればIDORは解決する」→ 不十分。UUID化はIDの推測を困難にする補助策にすぎず、サーバサイドの所有者確認（認可チェック）を省略してよい理由にはなりません。

誤り② 「ログイン機能があり認証さえ実装していればIDORは発生しない」→ 誤。IDORは認証済みユーザが自分以外のリソースIDを指定することで成立する、認可（Authorization）レベルの不備です。認証の有無とは別問題です。

誤り③ 「フロントエンドでボタンを非表示にすれば権限のない操作は防げる」→ 誤。UI上の非表示はあくまで見た目の制御であり、攻撃者は開発者ツールやAPIを直接呼び出すことでリクエストを送信できます。サーバサイドでの検証が必須です。

関連用語

重要キーワード

用語説明
IDORオブジェクトIDの直接操作により認可チェックを回避してアクセスできる脆弱性
BOLAオブジェクトレベルの認可不備。IDORとほぼ同義でOWASP API Top 10の1位
BFLA機能（エンドポイント）レベルの認可不備。垂直権限昇格の原因
水平権限昇格同一権限レベルの他ユーザのリソースにアクセスできる状態
垂直権限昇格より高い権限レベルの機能・データにアクセスできる状態
間接参照推測困難な識別子やマッピングを介して内部IDを直接露出させない設計