インセキュア・ダイレクト・オブジェクト・リファレンス（IDOR）とは？

インセキュア・ダイレクト・オブジェクト・リファレンス（IDOR）とは？

インセキュア・ダイレクト・オブジェクト・リファレンス（IDOR）は、攻撃者がアプリケーションリクエスト内のオブジェクト識別子を操作することで、他ユーザーのデータへアクセスできてしまうアクセス制御の脆弱性です。アプリケーションがデータベースキーやファイル名、レコードIDなどをユーザーに直接公開し、リクエストしたユーザーがそのオブジェクトの所有者かどうかを検証しない場合、認証済みの任意のユーザーがURL内の数字を変更するだけで他ユーザーのデータを閲覧・変更できてしまいます。

IDORは、過去最大級のデータ漏洩の原因となっています。2019年、First American Financial Corporationは、アプリケーションがURLパラメータを変更するだけで他ユーザーのドキュメントにアクセスできる設計だったため、社会保障番号や銀行口座情報を含む8億枚以上の画像を漏洩しました。

根本的な失敗は単純です。アプリケーションはユーザーがログインしていること（認証）は確認しますが、特定のレコードにアクセスする権限があるか（認可）は確認しません。つまり、玄関の鍵は確認するものの、中に入った後は誰でもすべての書類キャビネットを開けられる状態です。

IDORは CWE-639（ユーザー制御キーによる認可バイパス）に該当します。APIの文脈では、同じ脆弱性がBroken Object Level Authorization（BOLA）と呼ばれ、 OWASP API1（API1:2023）で第1位に位置付けられています。その親カテゴリであるBroken Access Controlは、 OWASP Top 10で第1位となっており、 2025年版でもその位置を維持しています。

仕組みを詳しく見る前に、IDORがどのような形態を取り、既存の脆弱性フレームワークでどのように分類されているかを理解しておくと役立ちます。

インセキュア・ダイレクト・オブジェクト・リファレンスの種類

IDORは単一の一様な欠陥ではありません。関与する権限関係や公開されるオブジェクトの種類によって、さまざまな形で現れます。

水平型IDOR

最も一般的な形態です。認証済みユーザーが同じ権限レベルの他ユーザーのオブジェクトにアクセスします。例えば、/api/users/123/profile を /api/users/124/profile に変更して他アカウントのデータを閲覧するケースです。権限昇格は発生せず、攻撃者は同一階層内でアカウントの境界を越えるだけです。

垂直型IDOR

攻撃者が自身の権限よりも高い権限が必要なオブジェクトにアクセスします。例えば、管理者レコードや制限された設定エンドポイント、管理機能などに識別子を操作して到達するケースです。垂直型IDORは、Honda eCommerceの事例のように、ディーラーレベルからプラットフォーム管理者への完全な権限昇格につながることがあります。

API型IDOR（BOLA）

RESTやGraphQL APIでは、同じ欠陥がBroken Object Level Authorization（BOLA）という別名で呼ばれます。APIのステートレスな性質により、このバリアントは特に蔓延しやすくなっています。1つの設定ミスが、認証済みセッションからコレクション内のすべてのレコードを露出させる可能性があります。

静的リソース型IDOR

ファイルダウンロード、エクスポート、レポートエンドポイントは、認可レビューで見落とされがちです。アプリケーションが /reports/invoice_1042.pdf でPDFを提供し、リクエストユーザーがその請求書の所有者かどうかを検証しない場合、この脆弱性はデータベースレコードIDORと構造的に同一です。このバリアントは、医療、金融、法務プラットフォームなど、規制データを扱う分野でよく見られます。

これら各形態は、確立された脆弱性フレームワーク内で異なる位置にマッピングされており、IDORの分類が複雑になる要因です。

OWASPによるインセキュア・ダイレクト・オブジェクト・リファレンスの分類

IDORは3つの異なる脆弱性フレームワークにまたがって登場し、それぞれが同じ根本的な失敗に対する異なる組織的視点を反映しています。

OWASP Top 10での位置付け

IDORは2007年から2013年まで単独のTop 10エントリでした。2017年にOWASPはこれをBroken Access Controlに統合し、2021年に第1位となり、2025年版でもその位置を維持しています。現在は40のCWEがこのカテゴリにマッピングされています。

OWASP API Security Top 10

IDORのAPI特有の表現であるBOLAは、2019年のAPI Security Top 10開始以来API1の位置を維持しています。API1:2023エントリでは、BOLAの悪用性（「容易」）と普及度（「広範」）が最高評価となっており、他のAPI脆弱性クラスよりも多くの報告が寄せられる理由となっています。

CWEマッピング

CWE-639（ユーザー制御キーによる認可バイパス）がIDORの主なMITRE分類です。その親はCWE-284（不適切なアクセス制御）です。SQLをバックエンドとする実装の最も具体的な子はCWE-566（ユーザー制御SQL主キーによる認可バイパス）です。CWE-639は2025 CWE Top 25に含まれています。

この分類体系を理解することで、実際にどのように悪用されるかを検証する準備が整います。

インセキュア・ダイレクト・オブジェクト・リファレンスの仕組み

IDORは、アプリケーションが認証と認可の間に存在する根本的なギャップを悪用します。以下の手順は、1つの公開された識別子がどのようにして大規模なデータ侵害につながるかを示しています。

ステップ1：アプリケーションがダイレクト・オブジェクト・リファレンスを公開

アプリケーションが内部オブジェクトに直接マッピングされるURLやAPIパラメータを生成します：

123の値は、ユーザーレコードのデータベース主キーであり、URLパスに直接公開されています。

ステップ2：攻撃者が識別子を変更

攻撃者が123を124に変更します。アプリケーションがユーザー124のプロフィールデータを返す場合、脆弱性が確認されます。

ステップ3：サーバーが認可チェックなしでオブジェクトを取得

 OWASPリファレンスは明確な脆弱なコードパターンを示しています

@login_requiredデコレーターはユーザーがログインしていることのみを確認します。ユーザー123がユーザー124のプロフィールにアクセスできるかどうかは検証しません。1行追加するだけで脆弱性は修正されます：

ステップ4：列挙による大規模悪用

攻撃者がパターンの有効性を確認すると、スクリプトを作成してID値を順に試し、単一の脆弱性を大規模なデータ侵害へと拡大します。アプリケーションによっては、この列挙は短時間で完了します。悪用の速さが、単なるアクセス制御の欠陥を大規模なデータ侵害へと変貌させます。

主な4つの攻撃面

これらの攻撃面は、アプリケーション設計・構築時のより深い構造的要因によって生じます。

インセキュア・ダイレクト・オブジェクト・リファレンスの原因

IDORは、構造的な設計判断や、開発者による一般的な誤解がアプリケーションアーキテクチャ全体で複合的に作用することで発生します。

認可の欠如とスコープされていないクエリ

主な原因は、ユーザーから受け取った入力値を使ってオブジェクトを取得する際、リクエストユーザーがそのレコードの所有者かどうかを検証しないアプリケーションです。これは、認証済みユーザーのデータセット(current_user.orders.find(order_id))ではなく、オブジェクトテーブル全体(Order.find(order_id))をクエリする「スコープされていない」データベースクエリとして最もよく現れ、すべてのレコードが認証済みセッションから露出します。

予測可能な識別子と直接キー公開

MITRE CWE-639はこれを明示的に指摘しています。連番や推測しやすいレコードIDを使用するシステムでは、攻撃者が値をインクリメントすることで他ユーザーのデータを列挙できます。特に整数の連番（1, 2, 3…）をURLやPOSTボディに直接公開することは、極めて予測しやすい攻撃面を生み出します。

UUIDに関する誤解

 OWASPチートシートはこれを直接指摘しています。GUIDのような複雑な識別子は有効な値の推測を事実上不可能にしますが、アクセス制御チェックは依然として不可欠です。攻撃者が共有リンクやアプリケーションレスポンスから有効なURLを入手した場合、アプリケーションは不正アクセスを必ずブロックしなければなりません。

ステートレスAPIアーキテクチャ

OWASP API1:2023は、API特有の構造的原因を指摘しています。サーバーがクライアントから送信されたオブジェクトIDなどのパラメータに依存してアクセス対象を決定するため、RESTやGraphQL APIは明示的なリクエストごとの認可ロジックがなければIDORに構造的に脆弱です。

これらの原因が放置されると、技術的な層を超えてビジネスインパクトが拡大する脆弱性となります。

インセキュア・ダイレクト・オブジェクト・リファレンスの影響とリスク

IDORの影響は、データ漏洩から完全なアカウント乗っ取りまで多岐にわたり、規制・財務・安全性の領域にまで及びます。

大規模なデータ漏洩

IDORの悪用はスクリプト化可能なため、単一の脆弱なエンドポイントでデータベース全体が露出することがあります。First AmericanのIDORでは 8億枚以上の画像が漏洩しました。Optusは、 アクセス制御の欠如があるAPIエンドポイントの放置により顧客記録を失いました。

規制・財務上の制裁

IDORによる侵害は、複数年にわたる規制執行を招きます。First Americanは SECや NYDFSから制裁を受けました。Optusも大きな財務的影響を受けました。

アカウント乗っ取りと権限昇格

IDORはデータの読み取りだけにとどまりません。HondaのeCommerceプラットフォームの事例では、研究者がID値を1つ変更するだけで全ディーラーのレコードにアクセスし、最終的にはHonda社員専用のプラットフォーム管理者権限まで昇格しました。

OWASP深刻度評価

 OWASP API Top 10は、BOLAの悪用性を「容易」、普及度を「広範」と評価しています。悪用の容易さと広範な普及の組み合わせが第1位の理由です。

これらの深刻度評価は、攻撃者がIDORを大規模に悪用する手法を反映しています。

攻撃者によるインセキュア・ダイレクト・オブジェクト・リファレンスの悪用方法

IDORの悪用は、最小限の技術的知識で実行できる構造化されたワークフローに従います。

パラメータの置換

攻撃者は識別子を他ユーザーの値に変更し、レスポンスを観察します。/api/users/123/profile を /api/users/124/profile に変更し、403 Forbiddenではなく200 OKが返れば脆弱性が確認されます。

自動列挙

確認後、攻撃者はBurp SuiteのIntruderモジュールやOWASP ZAP、カスタムスクリプトを使い、すべてのID値を順に試して悪用を拡大します。 OWASP APIドキュメントは、URL内のIDを操作する単純なスクリプトで数千件のレコードにアクセスできることを説明しています。

連鎖的な悪用

攻撃者はIDORを他の脆弱性と組み合わせます。Honda eCommerceの事例は、水平型データアクセスと垂直型権限昇格の連鎖を示しています。McDonald's McHireプラットフォームでは、IDORとデフォルト認証情報が組み合わさり、露出が拡大しました。

水平・垂直アクセス

 OWASPアクセス制御ガイドはその違いを明確にしています。IDORは最も一般的には水平型権限昇格（同一権限レベルの他ユーザーのデータへのアクセス）を可能にします。まれに、IDORが垂直型昇格（一般ユーザーが管理者権限を取得）を可能にします。

これらの手法の単純さから、ユーザーデータを扱うほぼすべてのアプリケーションが標的となり得ます。

インセキュア・ダイレクト・オブジェクト・リファレンスの影響を受ける対象

IDORは、ユーザーが制御可能な識別子を使ってオブジェクトへアクセスし、リクエストごとの認可チェックを行わないすべてのアプリケーションに影響します。

高リスクなアプリケーションアーキテクチャ

IDORリスクは、オブジェクトリファレンスを広範に公開したり、認可チェックを省略しやすくする構造的パターンによって増幅されます。

• リソースベースURLパターンのREST API。/resource/{id}のようなAPIは、設計上IDORの構造的リスクを持ちます。
• GraphQL API。引数ベースのオブジェクトアクセスで、リゾルバが所有権チェックを省略すると同様の脆弱性が生じます。
• マルチテナントSaaSアプリケーション。1つのテナントのユーザーがIDを操作して他テナントのデータにアクセスします。
• IoT・モバイルAPIバックエンド。複雑な認証フローや限定的なサーバーサイド状態管理によりBOLAリスクが高まります。
• ECプラットフォーム。注文ID、請求書ID、顧客アカウントリファレンスは高価値ターゲットです。

これらすべてのアーキテクチャに共通するのは、オブジェクトアクセスがクライアント制御の識別子に依存し、サーバーがデータ返却前に所有権チェックを行わない点です。

高リスク業界

最もリスクが高い業界は、オブジェクトリファレンスが機密記録や規制データ、物理システムに直接マッピングされる分野です。

• 医療： CVE-2024-28320（Hospital Management System、CVSS 7.6）で患者データの読み取り・変更が可能に。
• 金融サービス： 決済プラットフォームやタイトル会社はデータ漏洩と規制リスクの両方に直面。
• 政府：  HackerOneによると、政府プログラムでもIDORが繰り返し報告されています。
• 自動車： Pandora/Viper事例やCVE-2025-11690は車両システムへの実害リスクを示しています。

これら業界での実際の侵害事例は、IDORを放置した場合の現実的な影響を示しています。

インセキュア・ダイレクト・オブジェクト・リファレンスの実例

以下の事例は、IDORがさまざまな業界やアプリケーションタイプでどのように発生したかを示しています。いずれも、ユーザー入力の識別子が、リクエスト者がそのオブジェクトの所有者かどうかをサーバーが確認しないという同じ根本的失敗に起因しています。

First American Financial Corporation（2019年）

First AmericanのEagleProアプリケーションは、任意のユーザーがURLパラメータを変更するだけで他ユーザーのエスクローやタイトル文書にアクセスできました。この脆弱性は2014年に導入され、5年間放置されました。社会保障番号や住宅ローン支払い書類を含む8億枚以上の画像が露出しました。規制上の制裁は SEC提出書類や NYDFS提出書類に記載されています。CISA、NSA、オーストラリア信号局はこの事例を IDORに関する共同勧告で引用しています。

Optusデータ侵害（2022年）

2018年のコーディングエラーにより、OptusのAPIエンドポイントでアクセス制御が破壊されました。Optusは2021年にメインドメインのエラーを修正しましたが、インターネット公開された別ドメインは未修正のままでした。2022年9月、攻撃者はこのアクセス制御の欠如を悪用し、顧客記録（有効な個人ID番号を含む）を流出させました。オーストラリア通信・メディア庁（ACMA）は、この攻撃が「高度なものではなく」「単純な試行錯誤」で実行されたと認定しています。これはオーストラリア史上最大のデータ侵害です。

McDonald's McHireチャットボット（2025年）

セキュリティ研究者 Ian Carroll氏とSam Curry氏は、McDonald'sが利用するParadox.ai McHireチャットボットAPIにIDORを発見しました。内部の/api/lead/cem-xhrエンドポイントでlead_id整数をデクリメントすることで、他応募者のチャット記録・連絡先・セッショントークンを認可チェックなしで取得できました。自身のlead_idは64,185,742であり、膨大な記録がアクセス可能だったことを示しています。この脆弱性は2025年6月30日に開示され、同日に修正されました。

PandoraおよびViperスマートカーアラーム（2019年）

Pen Test Partnersは、スマートカーアラームAPIにIDOR脆弱性を発見し、車両フリート全体のアカウント乗っ取りが可能であることを示しました。攻撃者はアカウントのパスワードやメールアドレスを変更し、車両の物理的制御を取得できました。研究者は、約300万台の高級車がベンダーによる迅速な修正前に露出していたと推定しています。

バグバウンティでのシグナル

IDORはバグバウンティプラットフォームで一貫して高額報酬の対象です。 PayPalの報告はHackerOneで高額バウンティを獲得し、 HackerOneのデータでもIDORが繰り返し報告される脆弱性クラスであることが示されています。

これらの事例は、IDORが主要な脆弱性フレームワークや実際の侵害で10年以上にわたり存在し続けていることを示しています。

インセキュア・ダイレクト・オブジェクト・リファレンスのタイムラインと歴史

IDORは、20年近くにわたり正式なセキュリティ分野の一部となっています。以下のタイムラインは、単独カテゴリから複数フレームワークに組み込まれる基礎概念への進化、API・IoT・AIシステムなど新たなインフラへの拡大までの流れを示します。

IDORが20年近く脆弱性トラッキングで継続していることから、自社アプリケーションで確実に検出する方法が必要です。

インセキュア・ダイレクト・オブジェクト・リファレンスの検出方法

IDORは、ツールだけでは発見が困難です。なぜなら、レスポンスコードのパターンマッチではなく、オブジェクト所有権やビジネスロジックの理解が必要だからです。

手動ペネトレーションテスト（必須）

 OWASP WSTGはテスト手順を定義しています：

1. ユーザー入力がオブジェクトを直接参照するすべての箇所をマッピング
2. オブジェクト参照に使われるパラメータ値を変更
3. 他ユーザーのオブジェクト取得や認可バイパスが可能か評価
4. 異なるHTTPメソッドやバルクアクセスパターンもテスト

手動テストは、パラメータ操作だけでなく認可意図を考慮できる唯一の方法です。各ユーザーロールがアクセスできる範囲を理解したテスターでなければ、スキャナーは代替できません。

アプリケーションセキュリティテストツール

OWASP ZAPやBurp SuiteなどのDASTツールは、マルチユーザーテストアカウントとクロスユーザーオブジェクトIDマッピングを設定することでIDORを検出できます。デフォルト設定ではIDORは検出されません。SASTツールは認可関数呼び出しの欠如をフラグできますが、実行時の認可ロジックの意味的正しさは判断できません。

ランタイム挙動監視

これは本番環境でIDORを現実的に検出できる唯一の運用コントロールです。以下のシグナルを監視します：

• 単一セッションからのオブジェクト参照エンドポイントへの連番・列挙パターンリクエスト
• リクエストユーザーが所有しないオブジェクトIDに対し200 OKを返す認証済みリクエスト
• 複数ユーザーアカウントにまたがる大量のオブジェクト参照リクエスト

事前テストと異なり、挙動監視は本番環境で継続的に機能し、実際の悪用を検知できます。これは、ライブデータに対するIDORの悪用を捕捉できる唯一のコントロールです。

セキュアコードレビュー

 認可チートシートによれば、コードレビューではすべてのリクエストで権限が検証されていること、 アクセス制御がメソッド単位でなくグローバルに実装されていることを確認する必要があります。ユーザー入力の識別子を受け付けるエンドポイントに特に注意し、パラメータ受け取りからデータベースクエリ、レスポンスまでのコードパスを追跡します。認証済みユーザーの権限でクエリをスコープせずにオブジェクトを取得するパスは、IDORリスクが確定します。

IDORの発見は第一歩に過ぎません。防止には、開発・運用ライフサイクル全体にコントロールを組み込む必要があります。

インセキュア・ダイレクト・オブジェクト・リファレンスの防止方法

防止には、設計・開発・テスト・運用監視にまたがる多層的アプローチが必要です。

設計段階：すべての機能に認可モデルを組み込む

Broken Access Controlを 攻撃面分析の一部として機能設計時に考慮します。コードを書く前に明示的な認可関数（canAccess, isOwnerパターン）を定義します。

開発段階：すべてのオブジェクトアクセスでサーバーサイド認可を強制

 IDORチートシートは以下のコントロールを指定しています：

1. ユーザーがアクセスしようとするすべてのオブジェクトに対しアクセス制御チェックを実装。クライアントから送信された識別子ではなく、セッション情報から認証済みユーザーを特定。チェックは集中型ミドルウェアで強制し、メソッド単位のロジックは避ける。
2. データベースクエリを認証済みユーザーのアクセス可能なデータセットにスコープ：

3. 難読化された外部値を内部データベースIDに変換する間接参照マップを、認可チェックと組み合わせて採用。

4. UUIDや長いランダム値を公開識別子として採用。これは多層防御の一部であり、主たるコントロールではない。

5. 識別子の暗号化は避ける。OWASPチートシートは「安全に実装するのが困難」と明記。

6. 静的リソースにも認可を強制。 認可チートシートで頻繁に見落とされる面と指摘。

これらのコントロールは、クライアント入力値を信頼せず、データ層で所有権を強制するため有効です。攻撃者がパラメータを操作しても、認可チェックでブロックされます。

テスト段階：マルチユーザー認可テスト

マルチユーザー構成でDASTスキャンを実施し、クロスアカウントアクセスをテスト。認可関数呼び出しの欠如をフラグするSASTルールを含める。ビジネスロジックIDORには手動ペネトレーションテストを優先。

運用段階：API挙動監視

挙動監視を導入し、通常のAPIアクセスパターンをベースライン化し、異常なオブジェクトアクセスを検知。SentinelOneのStoryline技術は、疑わしいアクセスパターンのAPIインタラクション全体とIDコンテキストを再構築し、IDOR悪用の有無を確認・否定するためのフォレンジックタイムラインを提供します。

これらのコントロールを効果的に実装するには、アプリケーションセキュリティテストと運用監視ツールの適切な組み合わせが必要です。

検出・防止のためのツール

IDORを完全にカバーする単一のツールは存在しません。効果的なカバレッジには、開発時スキャン・運用監視・手動検証を組み合わせた多層的アプローチが必要です。以下のツールは各フェーズで異なるカバレッジと制約を持ちます。

アプリケーションセキュリティテストツール

APIセキュリティ・挙動監視

挙動ベースAPI監視ツールは、通常のアクセスパターンをベースライン化し、異常を検知します。IDORリクエストは正規トラフィックと構文的に同一なため、本番環境でIDOR悪用を現実的に検出できる唯一の運用コントロールです。

関連する脆弱性

IDORはBroken Access Controlファミリーに属します。関連脆弱性タイプとの関係を理解することで、修正の優先順位付けに役立ちます。

• Broken Object Level Authorization（BOLA）、API1:2023。 IDORとBOLAはともにCWE-639にマッピングされます。BOLAはAPI特有の表現です。
• Broken Function Level Authorization（BFLA）、API5:2023 / CWE-285。 IDORがデータオブジェクト（アクセスできるレコード）を対象とするのに対し、BFLAはAPI機能（実行できる操作）を対象とし、主に垂直型権限昇格を可能にします。
• 強制ブラウジング（CWE-425）。 ナビゲーションやページレベルの制御をバイパスし、制限ページに直接アクセス。 Broken Access Controlの具体例として掲載。
• SQL主キー認可バイパス（CWE-566）。 CWE-639の直接の子であり、SQLバックエンドIDORの最も具体的なCWEです。
• 垂直型権限昇格（CWE-269 / CWE-285）。 攻撃者が識別子を操作して管理機能にアクセスすることで、IDORが 権限昇格に連鎖する場合があります（Honda eCommerce事例など）。

これら関連脆弱性パターンが本番システムでどのように現れるかを示す具体的なCVEも存在します。

関連CVE

AIを活用したサイバーセキュリティの実現

リアルタイムの検知、マシンスピードのレスポンス、デジタル環境全体の可視化により、セキュリティ態勢を強化します。

デモを見る

まとめ

インセキュア・ダイレクト・オブジェクト・リファレンスは、入力処理だけでなくオブジェクトレベルの認可を破壊するため、最も悪用されるWebセキュリティの失敗の1つであり続けています。アプリケーションがユーザー入力の識別子を所有権チェックなしで信頼すると、小さなURL変更が大規模なデータ露出につながります。 

このリスクを低減するには、すべてのオブジェクトアクセスで認可を強制し、複数ユーザーコンテキストでテストし、本番環境で悪用を監視することが重要です。