インセキュア・ダイレクト・オブジェクト・リファレンス（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がどのような形態を取り、既存の脆弱性フレームワークでどのように分類されているかを理解しておくと役立ちます。
.jpg)
インセキュア・ダイレクト・オブジェクト・リファレンスの種類
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は、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つの攻撃面
| 攻撃面 | 例 |
| URLパスパラメータ | /invoices/1042 を /invoices/1043 に変更 |
| クエリストリングパラメータ | ?order_id=7001 を ?order_id=7002 に変更 |
| ファイルパラメータ | ?file=report_user1.pdf を ?file=report_user2.pdf に変更 |
| POSTボディの隠しフィールド | フォーム送信内のuser_idを他ユーザーのIDに変更 |
これらの攻撃面は、アプリケーション設計・構築時のより深い構造的要因によって生じます。
インセキュア・ダイレクト・オブジェクト・リファレンスの原因
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システムなど新たなインフラへの拡大までの流れを示します。
| 期間 | マイルストーン |
| 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セキュリティの失敗の1つであり続けています。アプリケーションがユーザー入力の識別子を所有権チェックなしで信頼すると、小さなURL変更が大規模なデータ露出につながります。
このリスクを低減するには、すべてのオブジェクトアクセスで認可を強制し、複数ユーザーコンテキストでテストし、本番環境で悪用を監視することが重要です。
よくある質問
IDORは、レコード所有権の強制が失敗している状態です。サーバーが特定のオブジェクトへのアクセス権をユーザーごとに検証しない場合、ファイル名、注文番号、プロファイルIDなどを変更することで他者のデータが露出または改ざんされる可能性があります。実際には、IDORはまず認可の問題であり、次にパラメータ操作の問題です。
はい。古いOWASP資料ではIDORと呼ばれることがありますが、新しいガイダンスではBroken Access Controlに分類されています。APIを重視するチームでは同じ問題をBOLAと呼ぶこともあります。
異なる名称でも、根本原因は同じくオブジェクトレベルの認可が欠如していることです。
はい。攻撃者は通常、到達可能なエンドポイントとリクエストを送信する有効な手段だけが必要です。一般的にコード実行やマルウェア配信は必要ありません。
一つのオブジェクト参照パターンが機能すれば、スクリプト化されたリクエストで悪用が拡大するため、放置されたドメイン、古いAPIバージョン、公開されたモバイルバックエンドは特にリスクが高くなります。
オブジェクトの検索がクライアント入力によって行われる場合、アプリケーションは最も脆弱になります。多くのオブジェクト参照を公開するシステム、テナント間でインフラを共有するシステム、クライアントから送信されたIDを繰り返し信頼するステートレスAPIに依存するシステムではリスクが高まります。高リスクな操作には、ユーザー関連レコードの取得、更新、エクスポート、削除などがあります。
攻撃者は通常、アプリケーションがどのように名前付けしているかが明らかになる場所、つまりURLのID、隠しフォームフィールド、JSONボディ、APIレスポンスなどから開始します。その後、値を入れ替え、レスポンスを比較し、異なる手法やアカウントコンテキストでテストします。
ステータスコード、レスポンスサイズ、返却フィールドのわずかな違いでも、悪用可能なオブジェクトアクセスを確認できます。
最も早い兆候は通常、行動パターンに現れます。1つの認証済みIDが多数のオブジェクトIDをリクエストしたり、想定されるアカウントやテナントの境界を越えたり、通常のユーザー行動と一致しない順序でレコードにアクセスしたりする場合に注意が必要です。
IDORは通常、正当なHTTPトラフィック内に隠れるため、構文よりもコンテキストが重要です。
深刻度は、CVSSのようなスコアだけでなく、規模や再現性にも依存します。多くの脆弱性は脆弱なエクスプロイトチェーンを必要としますが、IDORは所有権チェックが欠如している場合、通常のアプリケーション動作で機能します。
漏洩するデータが限定的な場合から、アカウント乗っ取りや権限昇格まで、公開されているオブジェクトによって影響範囲が異なります。
場合によっては可能です。公開されたオブジェクトがパスワードリセット、管理設定、テナント境界、ワークフロー操作を制御している場合、IDORはより大規模な乗っ取りの第一歩となることがあります。
オブジェクトの業務機能によって、脆弱性が1つのレコードに留まるか、プラットフォーム全体のインシデントに拡大するかが決まります。
デフォルトでは困難です。ツールは入力を検出しリクエストを再送できますが、IDORは誰がどのオブジェクトを所有すべきか、セッションごとにロールがどう異なるかの理解が必要です。
最も効果的な方法は、自動化と準備された複数ユーザーのテストデータ、手動検証の組み合わせです。本番環境では、スキャナーだけに頼るよりも行動監視の方が現実的です。
最もリスクが高いのは、オブジェクト参照が機密レコード、規制対象データ、物理的な影響に直接結びつく業界です。実際には、医療記録、金融文書、政府データ、自動車システム、アイデンティティ管理資産などが該当します。
これらの環境では、1件の不正なオブジェクトアクセスが、プライバシー、コンプライアンス、不正、または安全性に重大な影響を及ぼす可能性があります。
