インセキュア・ダイレクト・オブジェクト・リファレンス（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 (2007–2013) | A4 | Insecure Direct Object References | 単独エントリとして存在、現在は統合済み |
| OWASP Top 10 (2021–2025) | A01 | Broken Access Control | #1（40のCWEをマッピング、CWE-639含む） |
| OWASP API Security Top 10 | API1:2023 | Broken Object Level Authorization (BOLA) | #1（容易な悪用性、広範な普及） |
| MITRE CWE | CWE-639 | Authorization Bypass Through User-Controlled Key | 2025 CWE Top 25 |
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は、API Security Top 10が2019年に開始されて以来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つの攻撃面
| 攻撃面 | 例 |
| URLパスパラメータ | /invoices/1042を/invoices/1043に変更 |
| クエリストリングパラメータ | ?order_id=7001を?order_id=7002に変更 |
| ファイルパラメータ | ?file=report_user1.pdfを?file=report_user2.pdfに変更 |
| POSTボディの隠しフィールド | フォーム送信内のuser_idを他ユーザーのIDに変更 |
これらの攻撃面は、アプリケーション設計・構築上のより深い構造的要因に起因します。
インセキュア・ダイレクト・オブジェクト・リファレンスの原因
IDORは、構造的な設計判断や開発者による一般的な誤解がアプリケーションアーキテクチャ全体で複合的に作用することで発生します。
認可の欠如とスコープされていないクエリ
主な原因は、ユーザー入力を用いてオブジェクトを取得する際、リクエストユーザーがそのレコードの所有者かどうかを検証しないアプリケーションです。これは、スコープされていないデータベースクエリとして最もよく現れます。すなわち、アプリケーションが全オブジェクトテーブルをクエリする(Order.find(order_id))のではなく、認証済みユーザーのデータセットに限定してクエリする(current_user.orders.find(order_id))べきところ、全レコードを認証済みセッションから露出させてしまいます。
予測可能な識別子と直接キー公開
MITRE CWE-639はこれを明示的に指摘しています。連番や推測しやすいレコードIDを用いるシステムでは、攻撃者が値をインクリメントすることで他ユーザーのデータを列挙できます。データベース主キーをURLやPOSTボディに直接公開すること、特に整数連番（1, 2, 3…）は、極めて予測しやすい攻撃面を生み出します。
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値を変更するだけで全ディーラーの記録にアクセスし、最終的に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システムなど新たなインフラへの拡大を追跡しています。
| 期間 | マイルストーン |
| 2007 | OWASPがTop Tenで「IDOR」用語をA4の単独カテゴリとして導入 |
| 2013-2014 | OWASP単独カテゴリ（A4）としての最終年。First AmericanのIDOR欠陥が導入 |
| 2017 | IDORがA5のBroken Access Controlに統合 |
| 2019 | OWASP API Security Top 10でBOLAがAPI1として導入。First Americanの開示。Pandora/Viperの露出が記録 |
| 2021 | Broken Access ControlがOWASP Top 10で1位に |
| 2022 | Optus侵害、オーストラリア最大のデータ侵害 |
| 2023 | CISA/NSA/ACSCがIDORに関する共同勧告AA23-208Aを発表。BOLAがAPI1:2023で維持 |
| 2025 | Broken Access Controlが1位を維持し、40のCWEをマッピング。CWE-639が2025 CWE Top 25に掲載。McDonald's McHire IDORがIan Carroll氏とSam Curry氏により開示 |
| 2024-2026 | IDORがAI/LLMインフラ（CVE-2025-4962）、車両テレマティクス（CVE-2025-11690）、エンタープライズIAM（CVE-2024-56404）へ拡大。 HackerOneが IDOR報告の増加とXSS・SQLiの減少を確認。 |
IDORが約20年にわたり脆弱性トラッキングで継続していることから、自社アプリケーションで確実に検出する手法が必要です。
インセキュア・ダイレクト・オブジェクト・リファレンスの検出方法
IDORは、レスポンスコードのパターンマッチングではなく、オブジェクト所有権やビジネスロジックの理解が必要なため、ツールだけでの検出は困難です。
手動ペネトレーションテスト（必須）
OWASP WSTGはテスト手順を定義しています：
- ユーザー入力がオブジェクトを直接参照する全箇所をマッピング
- オブジェクト参照に使われるパラメータ値を変更
- 他ユーザーのオブジェクト取得や認可バイパスが可能か評価
- 異なるHTTPメソッドやバルクアクセスパターンもテスト
手動テストは、パラメータ操作だけでなく認可意図を考慮できる唯一の手法です。各ユーザーロールが何にアクセスできるべきかを理解したテスターでなければ、スキャナーは代替できません。
アプリケーションセキュリティテストツール
OWASP ZAPやBurp SuiteなどのDASTツールは、マルチユーザーテストアカウントとクロスユーザーオブジェクトIDマッピングを設定することでIDORを検出できます。デフォルト設定ではIDORは検出されません。SASTツールは認可関数呼び出しの欠如をフラグできますが、実行時に認可ロジックが意味的に正しいかどうかは判断できません。
ランタイム行動監視
これは本番環境で現実的にIDORを検出できる唯一の運用コントロールです。以下のシグナルを監視します：
- 単一セッションからのオブジェクト参照エンドポイントへの連番・列挙パターンリクエスト
- リクエストユーザーが所有しないオブジェクトIDに対し200 OKを返す認証済みリクエスト
- 複数ユーザーアカウントにまたがる大量のオブジェクト参照リクエスト
事前テストと異なり、行動監視は本番環境で継続的に機能し、実際の悪用を検知できます。これは、ライブデータに対するIDORの悪用を捕捉できる唯一のコントロールです。
セキュアコードレビュー
認可チートシートによれば、コードレビューでは全リクエストで権限が検証されていること、 アクセス制御がグローバルに実装されていることを確認する必要があります。ユーザー入力識別子を受け付けるエンドポイントに特に注意し、パラメータ受け取りからデータベースクエリ、レスポンスまでのコードパスを追跡します。認証済みユーザーの権限にスコープされていないクエリでオブジェクトを取得するパスは、IDORリスクが確定します。
IDORの検出は第一歩に過ぎません。防止には、開発・運用ライフサイクル全体にコントロールを組み込む必要があります。
インセキュア・ダイレクト・オブジェクト・リファレンスの防止方法
防止には、設計・開発・テスト・運用監視にまたがる多層的アプローチが必要です。
設計段階：全機能に認可モデルを組み込む
Broken Access Controlを 攻撃面分析の一部として機能設計時に考慮します。明示的な認可関数（canAccess, isOwnerパターン）をコード記述前に定義します。
開発段階：全オブジェクトアクセスでサーバーサイド認可を強制
IDORチートシートは以下のコントロールを指定しています：
- ユーザーがアクセスしようとする全オブジェクトに対しアクセス制御チェックを実装。クライアント送信識別子ではなく、セッション情報から認証済みユーザーを特定。チェックは個別メソッドではなく集中型ミドルウェアで強制。
- データベースクエリを認証済みユーザーのアクセス可能データセットにスコープ：
難読化された外部値を内部データベースIDに変換する間接参照マップを認可チェックと組み合わせて使用。
UUIDや長いランダム値を公開識別子として採用（多層防御の一環であり、主たるコントロールではない）。
識別子の暗号化は避ける。OWASPチートシートは「安全な実装が困難」と明記。
- 静的リソースにも認可を強制。 認可チートシートで頻繁に見落とされる面。
これらのコントロールは、クライアント送信値を信頼せずデータ層で所有権を強制するため有効です。攻撃者がパラメータを操作しても、認可チェックでブロックされます。
テスト段階：マルチユーザー認可テスト
クロスアカウントアクセスをテストするマルチユーザー構成でDASTスキャンを実施。認可関数呼び出しの欠如をフラグするSASTルールを含める。ビジネスロジックIDORには手動ペネトレーションテストを優先。
運用段階：API行動監視
行動監視を導入し、通常のAPIアクセスパターンをベースライン化し異常なオブジェクトアクセスを検知。SentinelOneのStoryline技術は、APIインタラクション全体と疑わしいアクセスパターンのIDコンテキストを再構築し、IDOR悪用の有無を確認・否定するためのフォレンジックタイムラインを提供します。
これらのコントロールを効果的に実装するには、アプリケーションセキュリティテストと運用監視ツールの適切な組み合わせが必要です。
検出・防止のためのツール
IDORを完全にカバーする単一ツールは存在しません。効果的なカバレッジには、開発時スキャン・運用監視・手動検証を組み合わせた多層的アプローチが必要です。以下のツールは各フェーズで異なるカバレッジと制約を持ちます。
アプリケーションセキュリティテストツール
| ツール種別 | 機能 | IDORカバレッジ | 制約 |
| DAST（OWASP ZAP、Burp Suite） | HTTP/S経由で稼働中アプリケーションをテスト | マルチユーザー構成でIDORを検出 | クロスアカウントテストシナリオの手動設定が必要 |
| SAST（SonarQube、Checkmarx） | ホワイトボックスソースコード解析 | 認可呼び出しパターンの欠如をフラグ | 認可ロジックの意味的正当性は検証不可 |
| IAST（Contrast Security） | QAテスト中のアプリ内エージェント | ランタイム行動コンテキストで誤検知が少ない | 計測済みテスト環境が必要 |
| 手動ペンテスト | ビジネスロジック・マルチユーザーシナリオ | 複雑な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
| CVE ID | 説明 | 深刻度 | 影響製品 | 年 |
| Tableau Serverのtab-doc APIモジュールにおけるCWE-639 IDOR。隣接ネットワーク上の攻撃者がユーザー制御キーを操作し、認可をバイパスして本番データベースクラスタへアクセス | 高 | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| Tableau Serverのset-initial-sql tabdocコマンドにおけるCWE-639 IDOR。認証済み低権限ユーザーがユーザー制御パラメータを操作し、本番データベースクラスタへアクセス | 高 | Salesforce Tableau Server (<2025.1.3) | 2025 | |
| Chainlitのスレッドリソース処理におけるCWE-639 IDOR。認証済みユーザーが他ユーザーのスレッドIDを指定し、所有権検証なしに会話データへアクセス | 中 | Chainlit | 2025 | |
| Five Star Restaurant Reservations WordPressプラグインにおけるCWE-639 IDOR。未認証攻撃者が予約識別子を操作し、他ユーザーのレコードを閲覧・変更・削除可能 | 中 | Five Star Restaurant Reservations WP plugin (≤2.7.8) | 2025 | |
| One Identity Identity ManagerのIDORにより、オンプレミス環境で権限昇格が可能。攻撃者がオブジェクト参照を操作し、割り当てられた役割を超える権限を取得 | クリティカル | One Identity Identity Manager 9.x (<9.3) | 2024 | |
| SO Planningツールの未認証IDOR。パブリックビュー有効時、攻撃者がエクスポートエンドポイントへ直接リクエストし、基盤データベース全体をCSVでダウンロード可能 | クリティカル | SO Planning (<1.52.02) | 2024 | |
| WooCommerce Stripe Payment Gatewayの未認証IDOR。注文所有権検証の欠如により、未認証ユーザーが90万以上のインストールで任意注文の請求名・メール・住所を閲覧可能 | 高 | WooCommerce Stripe Payment Gateway WP plugin (≤7.4.0) | 2023 | |
| ExtremePacs Extreme XDS医用画像プラットフォームにおけるCWE-639 IDOR。ユーザー制御キー操作により、認可なしで他患者の画像記録へアクセス可能 | 高 | ExtremePacs Extreme XDS (<3914) | 2023 | |
| 共有ストーカーウェアバックエンドサーバーのIDORにより、数十万台のデバイスからテキストメッセージ・通話記録・写真・位置情報が露出。CISA/NSA/ACSC勧告AA23-208Aで名指し | 高 | 1byte / 複数ストーカーウェアアプリ | 2022 | |
| Telos Alliance Omnia MPX Nodeのパスワードリセット機能におけるIDOR。攻撃者が任意ユーザーのアカウント識別子を指定し、パスワードをリセットして管理者アカウント含む完全なアカウント乗っ取りが可能 | 高 | Telos Alliance Omnia MPX Node (1.0.0–1.4.x) | 2022 |
まとめ
インセキュア・ダイレクト・オブジェクト・リファレンスは、入力処理だけでなくオブジェクトレベルの認可を破壊するため、最も悪用されるWebセキュリティの失敗の一つです。アプリケーションがユーザー入力の識別子を所有権チェックなしで信頼すると、小さなURL変更が大規模なデータ露出につながります。
このリスクを低減するには、全オブジェクトアクセスで認可を強制し、複数ユーザーコンテキストでテストし、本番環境で悪用を監視することが重要です。
よくある質問
IDORは、レコード所有権の強制が失敗している状態です。サーバーが特定のオブジェクトへのアクセス権をユーザーごとに検証しない場合、ファイル名、注文番号、プロファイルIDなどを変更することで、他人のデータが露出または改ざんされる可能性があります。実際には、IDORはまず認可の問題であり、次にパラメータ操作の問題です。
はい。古いOWASP資料ではIDORと呼ばれることがありますが、新しいガイダンスではBroken Access Controlに分類されています。APIに特化したチームでは、同じ問題をBOLAと呼ぶこともあります。
異なる名称でも、根本原因は同じであり、オブジェクトレベルの認可が欠如していることを指します。
はい。攻撃者は通常、到達可能なエンドポイントとリクエストを送信する有効な手段だけが必要です。一般的にコード実行やマルウェア配信は必要ありません。
一つのオブジェクト参照パターンが機能すれば、スクリプト化されたリクエストで悪用が拡大するため、放置されたドメイン、古いAPIバージョン、公開されたモバイルバックエンドは特にリスクが高くなります。
オブジェクトの検索がクライアント入力によって行われる場合、アプリケーションは最も脆弱になります。多くのオブジェクト参照を公開するシステム、テナント間でインフラを共有するシステム、クライアントから送信されたIDを繰り返し信頼するステートレスAPIに依存するシステムではリスクが高まります。高価値な操作には、ユーザー関連レコードの取得、更新、エクスポート、削除などが含まれます。
攻撃者は通常、アプリケーションがどのように名前付けしているかが明らかになる場所、つまりURLのID、隠しフォームフィールド、JSONボディ、APIレスポンスなどから開始します。その後、値を入れ替え、レスポンスを比較し、異なる手法やアカウントコンテキストをテストします。
ステータスコード、レスポンスサイズ、返却フィールドのわずかな違いでも、悪用可能なオブジェクトアクセスを確認できます。
最も早い兆候は通常、行動面に現れます。1つの認証済みIDが多数のオブジェクトIDをリクエストしたり、想定されるアカウントやテナントの境界を越えたり、通常のユーザー行動と一致しない順序でレコードにアクセスしたりする場合は注意が必要です。
IDORは通常、他の正当なHTTPトラフィックに紛れて発生するため、構文よりもコンテキストが重要です。
深刻度は、規模や信頼性にも大きく依存します。多くの脆弱性は脆弱なエクスプロイトチェーンを必要としますが、IDORは所有権チェックが欠如している場合、通常のアプリケーション動作で機能することが多いです。
露出するオブジェクトによって、限定的なデータ漏洩からアカウント乗っ取りや権限昇格まで影響範囲が広がります。
場合によっては可能です。露出したオブジェクトがパスワードリセット、管理設定、テナント境界、ワークフロー操作を制御している場合、IDORはより大規模な乗っ取りの第一歩となることがあります。
オブジェクトの業務機能によって、脆弱性が1つのレコードに留まるか、プラットフォーム全体のインシデントに拡大するかが決まります。
デフォルトでは困難です。ツールは入力を検出しリクエストを再送できますが、IDORはどのユーザーがどのオブジェクトを所有すべきか、セッションごとの役割の違いを理解する必要があります。
最も効果的な方法は、自動化と準備された複数ユーザーのテストデータ、手動検証を組み合わせることです。本番環境では、スキャナーだけに頼るよりも行動監視の方が現実的です。
最もリスクが高いのは、オブジェクト参照が機密レコード、規制対象データ、物理的な影響に直接結びつく業界です。実際には、医療記録、金融文書、政府データ、自動車システム、ID管理資産などが該当します。
これらの環境では、1件の不正なオブジェクトアクセスが、プライバシー、コンプライアンス、不正、または安全性に重大な影響を及ぼす可能性があります。
