IDORとは？安全でない直接オブジェクト参照の仕組み・被害事例・対策をわかりやすく解説

社内システムやWebアプリのAPIを見ていると、こんなURLに気づくことがあります。/api/users/123/profile というエンドポイントで、自分のユーザーIDが「123」なら、「124」に変えたら別のユーザーの情報が取れてしまうのでは？という疑問です。

この疑問が現実の脆弱性として顕在化したものが、IDOR（Insecure Direct Object Reference: 安全でない直接オブジェクト参照）です。シンプルな仕組みでありながら発見されにくく、悪用されると大量の個人情報が流出するリスクがあります。

OWASP Top 10の「A01: アクセス制御の不備（Broken Access Control）」の代表例として位置づけられており、世界中で実際の被害が発生しています。この記事では、IDORの仕組み・被害パターン・具体的な防御手順を、現場で使えるレベルで解説します。Webアプリを開発する人にも、社内システムを管理する情シス担当者にも、今日から役立つ内容です。

IDORとは？アクセス制御の不備が生む脆弱性

IDOR（Insecure Direct Object Reference）を直訳すると「安全でない直接オブジェクト参照」です。アプリケーションが、ユーザーのリクエストに含まれるオブジェクトID（ユーザーID・注文ID・ファイル名など）を、アクセス権限の確認なしに直接使用してしまう脆弱性です。

わかりやすく言えば、「番号さえわかれば鍵なしで開けられる引き出し」が存在している状態です。

IDORが問題になるのは、WebアプリケーションやAPIがデータベースのレコードを参照するとき、その「参照ID」をURLやリクエストパラメータに含める設計になっているためです。そのIDを変更したとき、サーバー側で「このユーザーがこのリソースにアクセスする権限があるか」を検証していないと、脆弱性が成立します。

OWASPが最上位リスクに位置づける理由

OWASPが2021年に発表したOWASP Top 10では、「A01: アクセス制御の不備（Broken Access Control）」がトップに位置づけられました。前回2017年版の5位から大幅に上昇し、現実の脅威として世界的に認識が高まっています。OWASPの調査では、テストされたアプリケーションの約94%に何らかのアクセス制御の欠陥が見つかったと報告されています。

IDORはこのカテゴリの中でも最も見つかりやすく、かつ広範に存在するパターンです。

IDORの攻撃が起きる仕組み（敵を知る）

1. 基本的なIDOR攻撃のパターン

最もシンプルな例を見てみましょう。オンラインショッピングサイトにログインし、注文詳細を確認するURLが次のようになっているとします。

# 注文詳細ページのURL例
https://example-shop.jp/orders/10542

攻撃者はこの番号を「10541」や「10543」に変えてアクセスします。サーバー側でアクセス権限チェックが行われていなければ、他のユーザーの注文情報（氏名・配送先住所・購入商品）が表示されてしまいます。

この攻撃が成立する条件は次の3つです。
・リクエストにオブジェクトIDが含まれている（URL・パラメータ・リクエストボディのいずれか）
・IDが予測可能または推測しやすい（連番の整数など）
・サーバー側でアクセス権限を確認していない

2. REST APIでのIDOR

近年はREST APIを使ったWebアプリが主流になり、IDORの舞台もAPIに移行しています。プロフィール取得APIが次のような設計だとします。

# プロフィール取得APIのリクエスト例
GET /api/v1/users/profile?user_id=789
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

攻撃者は自分のuser_id（例: 789）を別の値（例: 790）に変えてリクエストを送ります。トークンで「ログイン済みか」は検証されていても、「自分自身のデータにしかアクセスできないか」が検証されていない場合、他ユーザーのプロフィール情報が返ってしまいます。

JWTトークンのような認証機構があっても、認可チェックを怠れば意味をなしません。この「認証と認可の混同」がIDORの温床です。

3. ファイルダウンロードでのIDOR

ファイルダウンロードのAPIやURLでも同じ問題が起きます。

# ファイルダウンロードURLの例
GET /api/download?file_id=report_Q3_user789.pdf

このfile_idを変えると、他のユーザーがアップロードした機密ファイルをダウンロードできる可能性があります。給与明細・契約書・個人情報を含む帳票など、企業にとって致命的な情報が漏れるケースが実際に報告されています。

4. HTTPメソッドを変えた高度なパターン

IDORはデータの「読み取り」だけにとどまりません。更新・削除操作でも同様の問題が起きます。

# 他ユーザーのアカウント設定を変更する例
PUT /api/users/790/settings
{"email": "attacker@evil.com"}

# 他ユーザーのデータを削除する例
DELETE /api/orders/10541

読み取りは「盗み見」ですが、更新・削除は「改ざん」や「サービス妨害」に発展します。被害の深刻度は格段に上がります。

IDORで実際に起きる被害パターン

IDORが悪用されると、次のような被害が発生します。

・個人情報の大量漏洩: 連番IDを自動化スクリプトで総当たりすれば、数万件のユーザー情報を短時間で取得できます
・他ユーザーデータの改ざん・削除: 閲覧だけでなく、変更・削除まで可能なケースでは業務データが破壊されます
・機密ファイルの流出: 契約書・財務報告書・個人の医療情報などが対象になります
・アカウント乗っ取りへの踏み台: パスワードリセットトークンやセッション情報が取得できれば、完全なアカウント乗っ取りに発展します
・内部不正への悪用: 権限を超えたデータ閲覧は、外部攻撃だけでなく内部犯行にも使われます

被害規模の現実

セキュリティ研究者のバグバウンティ報告によると、中規模のSaaSサービスでIDOR脆弱性が発見された場合、理論上は全ユーザーのデータが取得可能な状態になっています。IDが連番設計になっているシステムで自動化ツールを使えば、1時間あたり数万件のレコードを収集することは技術的に難しくありません。

HackerOneやBugcrowdの開示レポートでも、IDORは毎年最も多く報告される脆弱性カテゴリの1つです。報奨金（バグバウンティ）の観点からも、攻撃者にとって「費用対効果の高い」脆弱性として狙われやすい傾向があります。

具体的な防御手順

1. サーバーサイドで必ず認可チェックを実装する

IDORの根本原因は、「認証（ログインしているか）」と「認可（このリソースにアクセスしてよいか）」を混同していることにあります。ログイン確認だけでは不十分で、リソースへのアクセスごとに「このユーザーがこのリソースの所有者か、またはアクセス権限を持つか」を必ず確認してください。

# 認可チェックの実装例（Pythonの疑似コード）
def get_order(request, order_id):
    order = Order.find(order_id)

    # 認可チェック: リソースの所有者か確認
    if order.user_id != request.current_user.id:
        raise PermissionDenied("このリソースへのアクセス権限がありません")

    return order

チェックが必要なタイミングは次の通りです。
・GET（データ取得）時
・PUT/PATCH（データ更新）時
・DELETE（データ削除）時
・ファイルダウンロード・アップロード時

フレームワークに認可機能（Spring Security、Laravel Policy、Django Permission、Rails CanCanCan等）が搭載されている場合は積極的に活用してください。自前実装よりも安全で、テストも容易です。

2. 予測困難なIDを使用する（UUID活用）

連番の整数IDはIDORのリスクを高めます。代わりにUUID（Universally Unique Identifier）を使うことで、攻撃者がIDを推測しにくくなります。

重要な注意点: UUIDはIDを推測されにくくする「緩和策」であり、認可チェックの代替にはなりません。「IDを知らなければアクセスできない」という状態を作るだけで、「知っている人なら誰でもアクセスできる」という問題は残ります。必ず認可チェックと組み合わせて使ってください。

3. 間接参照マップでIDをユーザーから隠す

アプリケーションが内部のデータベースIDをユーザーに直接公開しないように設計する方法です。セッションスコープで「ユーザーがアクセスできるリソースのマッピング」を保持し、ユーザーには一時的なキーのみを渡します。

# 間接参照マップの実装イメージ（Pythonの疑似コード）
session['accessible_orders'] = {
    'tok-abc123': 10542,  # 実際のorder_id
    'tok-def456': 10890
}

# APIレスポンスにはトークンのみ含める
# {"order_token": "tok-abc123", "total": 12800}

# 次のリクエストではトークンで参照
def get_order(request, order_token):
    real_order_id = session['accessible_orders'].get(order_token)
    if not real_order_id:
        raise NotFound()
    return Order.find(real_order_id)

URLに実際のデータベースIDを含めないため、IDORの攻撃面が大幅に減ります。セッションの管理コストはかかりますが、機密性の高いリソースには特に有効な設計です。

4. セキュリティテストでIDORを早期発見する

開発フェーズでIDORを見つけるために、次のテスト手法が有効です。

・2アカウントを使った手動テスト: アカウントAのリソースIDをアカウントBのセッションでアクセスし、データが返るか確認する
・BurpSuiteでのプロキシテスト: リクエストを傍受してIDパラメータを手動変更し、レスポンスを確認する
・OWASP ZAPの自動スキャン: 無料ツールで基本的なIDORチェックを自動化できる
・コードレビューでの重点確認: ID参照箇所のコードに必ず認可チェックが実装されているか確認する

CI/CDパイプラインに自動テストを組み込み、新機能追加のたびにIDORチェックを実行する仕組みを整えると、長期的なセキュリティ維持に効果的です。

5. 詳細なアクセスログを記録する

IDORの試みを事後に検知するために、アクセスログを詳細に記録することが重要です。

# ログに記録すべき情報
- タイムスタンプ
- リクエストユーザーID
- アクセスされたリソースID
- リクエストした操作（GET/PUT/DELETE等）
- 認可チェックの結果（成功/失敗）
- クライアントIPアドレス

認可チェックが失敗したログを監視し、同一ユーザーから短時間に多数の失敗が記録された場合はアラートを上げる仕組みを作ることで、攻撃の試みを早期に検知できます。

中小企業でも今日からできること

開発ベンダーに外注している場合でも、発注者側でIDORリスクを低減できます。

・セキュリティ要件を仕様書に明記する: 「全リソースアクセスに認可チェックを実装すること」を要件として記載し、受け入れテストの条件にする
・2アカウントテストを受け入れ条件にする: 納品前のテストとして、異なるユーザーのセッションでIDORチェックを必ず実施する
・WAFでの異常検知: WAFはIDORを直接防げませんが、同一IPからの連番IDアクセスのような異常パターンをアラートで検知できます
・ログ監視の整備: ユーザーIDとアクセスリソースIDのログを記録し、権限エラーの多発を検知する
・OWASP ZAPによる無料スキャン: 既存システムのIDOR確認は、OWASP ZAP（無料）を使って費用ゼロで始められます

まずは基幹業務システムの主要エンドポイントから確認することをおすすめします。特に「ユーザーIDや注文IDがURLやパラメータに含まれているエンドポイント」を優先してチェックしてください。

よくある誤解と注意点

【誤解1】「HTTPSを使っているから安全」

HTTPSは通信経路の暗号化であり、アクセス制御とは無関係です。HTTPSを使っていても、IDORは完全に成立します。「通信が暗号化されている」と「権限のないユーザーがアクセスできない」はまったく別の話です。

【誤解2】「ログインが必要なシステムだから大丈夫」

ログイン（認証）と権限チェック（認可）は別物です。「ログイン済みのユーザー全員が全データにアクセスできる」状態では、IDORのリスクはゼロになりません。「ログインしていること」と「そのリソースにアクセスしてよいこと」は別に確認が必要です。

【誤解3】「社内システムだから外部攻撃は関係ない」

IDORによる内部不正のリスクも見逃せません。退職前の従業員・不満を持つ内部者が、権限外のデータを大量に取得する手段になります。特に個人情報保護法の観点から、内部のアクセス制御不備は重大なコンプライアンス違反になります。

【誤解4】「フロントエンドで非表示にすれば見えない」

フロントエンドの制御は攻撃者にとって意味がありません。ブラウザの開発者ツールやBurpSuiteを使えば、非表示にされたIDを簡単に確認できます。セキュリティの制御は必ずサーバーサイドで実装してください。

【誤解5】「オブジェクトIDをランダムにすれば解決する」

UUIDなどのランダムIDは「推測を困難にする」効果はありますが、それだけでは不十分です。URLが何らかの形でリークした場合（ログ・メール・ブックマーク等）、認可チェックがなければアクセスできてしまいます。必ず認可チェックとの組み合わせが必要です。

IDORセキュリティ チェックリスト

開発・レビュー時に使えるチェックリストです。

設計フェーズ
・オブジェクトIDを外部公開するAPIの一覧を洗い出したか
・連番IDではなくUUIDなど推測困難なIDを採用したか
・認可チェックのロジックを設計書に明記したか

実装フェーズ
・全てのリソース参照箇所にサーバーサイドの認可チェックを実装したか
・GET・PUT・PATCH・DELETEの全メソッドで認可チェックが動くか確認したか
・フレームワークの認可機能（Policy/Permission等）を活用しているか

テストフェーズ
・2つの異なるユーザーアカウントを使ったIDORテストを実施したか
・認可エラー時に適切なHTTPステータス（403 Forbidden）を返しているか
・ファイルダウンロード・アップロードのエンドポイントもテスト対象に含めたか

運用フェーズ
・認可失敗のログを記録・監視しているか
・異常なアクセスパターン（大量の認可失敗等）のアラートを設定しているか
・定期的なセキュリティスキャン（OWASP ZAP等）を実施しているか

よくある質問（FAQ）

Q. IDORはWebアプリだけの問題ですか？
A. モバイルアプリのAPIや、マイクロサービス間の内部APIでも同様のリスクがあります。通信プロトコルに関係なく、リソースIDを参照する際に認可チェックが必要という点は共通です。

Q. GraphQL APIでもIDORは起きますか？
A. 起きます。GraphQLでは、クエリで指定したオブジェクトIDに対して認可チェックが必要です。GraphQLではリゾルバ（Resolver）レベルで認可チェックを実装するか、専用のGraphQL認可ライブラリ（graphql-shield等）を活用することを推奨します。

Q. バグバウンティプログラムではIDORはどう評価されますか？
A. IDORは実際に他ユーザーのデータにアクセスできる場合、「高（High）」または「緊急（Critical）」の深刻度として評価されることが多いです。被害の範囲と取得できるデータの機密性によって報奨金額も変わります。

Q. IDORを悪用した場合、法的問題はありますか？
A. 自分がアクセス権限を持たないシステムやデータへのアクセスは、不正アクセス禁止法（不正アクセス行為の禁止等に関する法律）の違反にあたる可能性があります。セキュリティテストを行う場合は、必ず対象システムの管理者から書面による許可を取得してください。法的な詳細は専門家にご確認ください。

Q. 既存システムのIDOR対策はどこから手をつければよいですか？
A. 最初に「ユーザーIDや注文IDなどの数値がURLやAPIパラメータに露出しているエンドポイント」をリストアップしてください。次に、各エンドポイントで認可チェックが実装されているかコードを確認します。2アカウントを使った手動テストで実際に確認することも有効です。優先度は「個人情報・機密データへのアクセス」から順に対応してください。

本記事のまとめ

IDORは、シンプルな仕組みでありながら見過ごされやすく、悪用されると深刻な個人情報漏洩につながる脆弱性です。

「認証（ログインしているか）」と「認可（このリソースにアクセスしてよいか）」を別々に確認すること——これがIDOR対策の核心です。開発フェーズでこの設計を徹底するだけで、多くのIDOR脆弱性は防げます。

姉妹サイトLinuxMaster.JPでは、Linuxのファイル権限管理（chmod・chown）やSELinuxを使ったアクセス制御の実装方法を詳しく解説しています。サーバーサイドのセキュリティ強化に合わせてご参照ください。