什麼是不安全的直接物件參照（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 edition中維持該位置。

在檢視其運作機制之前，先了解 IDOR 的不同形式以及它在既有弱點框架中的定位會有所幫助。

不安全的直接物件參照的類型

IDOR 並非單一且一致的缺陷。它會依涉及的權限關係以及暴露的物件類型而有不同表現。

水平式 IDOR

最常見的形式。已驗證的使用者存取屬於相同權限層級同儕的物件，例如將 /api/users/123/profile 變更為 /api/users/124/profile 以讀取另一個帳戶的資料。不會發生權限提升；攻擊者只是跨越同一層級內的帳戶邊界。

垂直式 IDOR

攻擊者存取需要比其目前擁有更高權限的物件：透過操控識別碼到達管理員記錄、受限制的組態 endpoint，或管理功能。垂直式 IDOR 經常串連成完整的權限提升，例如在 Honda eCommerce 案例中，研究人員從經銷商層級存取提升到平台管理員。

API IDOR（BOLA）

在 REST 與 GraphQL API 中，相同的缺陷有一個不同名稱：Broken Object Level Authorization（BOLA）。API 的無狀態特性使此變體特別普遍。單一設定錯誤的 resolver 或路由處理常式，就可能將集合中的每一筆記錄暴露給任何已驗證的工作階段。

靜態資源 IDOR

檔案下載、匯出與報表端點在授權審查期間經常被忽略。如果應用程式在 /reports/invoice_1042.pdf 提供 PDF，卻未驗證提出請求的使用者是否擁有該發票，則此弱點在結構上與資料庫記錄 IDOR 完全相同。此變體常見於醫療、金融與法律平台，因為這些平台中的文件承載受監管資料。

這些形式各自對應到既有弱點框架中的不同位置，而這也正是 IDOR 分類變得複雜之處。

OWASP 對不安全的直接物件參照的分類

IDOR 橫跨三個獨立的弱點框架，每個框架都從不同的組織視角反映相同的底層失敗。

OWASP Top 10 排名

IDOR 在 2007 年至 2013 年期間是獨立的 Top 10 項目。2017 年，OWASP 將其整併至 Broken Access Control，該類別於 2021 年升至第 1 名，並在 2025 年版本中維持該排名，現於此類別下對應 40 個 CWE。

OWASP API Security Top 10

BOLA 是 IDOR 在 API 情境中的特定表述，自 API Security Top 10 於 2019 年推出以來，一直位居 API1。API1:2023 項目將 BOLA 在可利用性（"Easy"）與普遍性（"Widespread"）兩方面都評為最高等級，這也是為何它持續產生比任何其他 API 漏洞類別更多的已回報發現。

CWE 對應

CWE-639（透過使用者控制金鑰繞過授權）是 IDOR 的主要 MITRE 分類。其父項為 CWE-284（Improper Access Control）。對於以 SQL 為後端的實作，最具體的子項是 CWE-566（Authorization Bypass Through User-Controlled SQL Primary Key）。CWE-639 出現在 2025 CWE Top 25 中。

理解此分類法，有助於進一步檢視此利用手法在實務中實際如何運作。

不安全的直接物件參照如何運作？

IDOR 利用的是應用程式驗證身分與授權控制之間的根本落差。以下步驟說明單一外洩識別碼如何演變為大規模資料外洩。

步驟 1：應用程式暴露直接物件參照

您的應用程式會產生一個 URL 或 API 參數，直接對應到內部物件：

數值 123 是使用者記錄的資料庫主鍵，直接暴露在 URL 路徑中。

步驟 2：攻擊者修改識別碼

攻擊者將 123 改為 124。如果應用程式回傳使用者 124 的個人資料，則可確認存在此漏洞。

步驟 3：伺服器在未進行授權檢查的情況下擷取物件

該 OWASP 參考資料提供了清楚的易受攻擊程式碼模式

The @login_required 裝飾器會確認使用者已登入，但不會驗證使用者 123 是否應該存取使用者 124 的個人資料。加入一行即可修補此漏洞：

步驟 4：透過列舉擴大利用規模

一旦攻擊者確認此模式可行，他們就會撰寫指令碼來反覆測試可能的 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 電子商務平台的已記錄案例中，研究人員透過變更單一 ID 值存取了每個經銷商的紀錄，接著進一步提升為完整平台管理員，此角色原本僅保留給 Honda 員工。

OWASP 嚴重性評等

The OWASP API Top 10 將 BOLA 評為「容易」利用且「普遍」存在。由於利用方式直接且盛行範圍廣泛的組合，這就是它位居第 1 名的原因。

這些嚴重性評等反映了攻擊者用來大規模利用 IDOR 的方法。

攻擊者如何利用不安全的直接物件參照

IDOR 利用遵循結構化工作流程，且僅需極少的技術能力。

參數替換

攻擊者將識別碼修改為另一位使用者的值，並觀察回應。將 /api/users/123/profile 改為 /api/users/124/profile，並收到 200 OK 回應而非 403 Forbidden，即可確認此弱點。

自動化列舉

一旦確認後，攻擊者會使用 Burp Suite 的 Intruder 模組、OWASP ZAP 或自訂指令碼來遍歷所有可能的 ID 值，以擴大利用規模。The OWASP API docs 說明了如何透過在 URL 中操作 ID 的簡單指令碼來取得對數千筆紀錄的存取權。

鏈式利用

攻擊者會將 IDOR 與其他弱點結合。Honda 電子商務案例展示了水平資料存取與垂直權限提升的鏈式利用。McDonald's McHire 平台則將 IDOR 與預設認證結合，進一步擴大曝險。

水平與垂直存取

The OWASP access control guide 釐清了兩者之間的差異。IDOR 最常見的是造成水平權限提升：使用者 A 以相同權限層級存取使用者 B 的資料。較少見的是，IDOR 會造成垂直提升：標準使用者取得管理員存取權。

這些技術的簡單性意味著，幾乎任何處理使用者資料的應用程式都可能成為目標。

哪些人會受到不安全直接物件參照的影響？

IDOR 會影響任何使用可由使用者控制的識別碼來存取物件，且未在每次請求中執行授權檢查的應用程式。

高風險應用程式架構

某些結構模式會放大 IDOR 風險，因為它們會更廣泛地暴露物件參照，或讓授權檢查更容易被略過。

• 具有以資源為基礎 URL 模式的 REST API。任何遵循 /resource/{id} 慣例的 API，在設計上都具有結構性的 IDOR 曝險。
• GraphQL API。當解析器略過擁有權檢查時，以引數為基礎的物件存取會產生相同的弱點。
• 多租戶 SaaS 應用程式。 某一租戶中的使用者會操作 ID 以存取另一租戶的資料。
• IoT 與行動 API 後端。 複雜的驗證流程與有限的伺服器端狀態管理會增加 BOLA 曝險。
• 電子商務平台。 訂單 ID、發票 ID 與客戶帳戶參照都是高價值目標。

這些架構的共同點在於，物件存取是由用戶端控制的識別碼所驅動，而伺服器在回傳資料前不會執行任何擁有權檢查。

高風險產業

曝險程度最高的產業，是那些物件參照直接對應到敏感紀錄、受監管資料或實體系統的產業。

• 醫療保健： CVE-2024-28320（Hospital Management System，CVSS 7.6）可讓攻擊者讀取及修改病患資料。
• 金融服務： 支付平台與產權公司同時面臨資料曝露與法規風險。
• 政府： According to HackerOne，政府計畫將 IDOR 視為反覆出現的問題。
• 汽車產業：Pandora/Viper 案例與 CVE-2025-11690 證實了車輛系統在真實世界中的風險。

這些產業中已有文件記錄的資料外洩事件，說明了未處理 IDOR 所帶來的真實世界後果。

不安全直接物件參照的真實世界案例

以下案例顯示 IDOR 如何在不同產業與應用程式類型中發生。每起事件都可追溯到相同的根本失敗：使用者提供的識別碼到達伺服器，而伺服器從未檢查請求者是否擁有被傳回的物件。

First American Financial Corporation（2019）

First American 的 EaglePro 應用程式允許任何使用者變更 URL 參數，並存取屬於其他使用者的託管與產權文件。此漏洞於 2014 年引入，持續存在了五年。超過 8 億張影像遭到暴露，其中包括社會安全號碼與房貸付款文件。監管處罰記錄於 SEC filing 和 NYDFS filing。CISA、NSA 與 Australian Signals Directorate 在其 joint advisory on IDOR中引用了此案例。

Optus 資料外洩事件（2022）

2018 年的編碼錯誤破壞了 Optus API 端點上的存取控制。Optus 於 2021 年修復了其主要網域上的錯誤，但卻讓一個被遺忘、面向網際網路的網域維持未修補狀態。2022 年 9 月，攻擊者利用這項失效的存取控制外洩客戶紀錄，其中包括有效的個人身分證號碼。澳洲通訊與媒體管理局（ACMA）證實，此次攻擊「並非高度複雜」，且是透過「簡單的反覆嘗試流程」實施的。這仍然是澳洲規模最大的資料外洩事件。

McDonald's McHire 聊天機器人（2025）

安全研究人員 Ian Carroll and 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 漏洞，使攻擊者能夠在整個車隊範圍內完全接管帳戶。攻擊者可以變更帳戶密碼或電子郵件地址，進而取得對車輛的實體控制權。研究人員估計，在供應商於揭露後數日內修補這些缺陷之前，約有三百萬輛高階車輛暴露於風險之中。

漏洞懸賞訊號

IDOR 在漏洞懸賞平台上是持續出現的高價值發現。一份 PayPal report 在 HackerOne 上獲得了可觀的獎金，而 HackerOne data顯示 IDOR 仍然是反覆出現的漏洞類別。

這些事件可追溯至 IDOR 在主要漏洞框架與真實世界資料外洩事件中存在的十多年歷史。

不安全直接物件參照的時間軸與歷史

IDOR 作為正式安全領域的一部分已將近二十年。以下時間軸追蹤其從獨立命名類別演變為嵌入多個框架中的基礎概念，以及其持續擴展至 API、IoT 與 AI 系統等較新的基礎架構。

由於 IDOR 在近二十年的弱點追蹤中持續存在，您需要可靠的方法來在自己的應用程式中找出它。

如何偵測不安全的直接物件參考

僅靠工具很難找到 IDOR，因為這需要針對物件擁有權與業務邏輯進行推理，而不是對回應代碼做模式比對。

手動滲透測試（必要）

The OWASP WSTG 定義了測試程序：

1. 對所有使用者輸入直接參考物件的位置進行對應整理。
2. 修改用於參考物件的參數值。
3. 評估您是否能擷取屬於其他使用者的物件或繞過授權。
4. 測試不同的 HTTP 方法與大量存取模式。

手動測試是唯一能針對授權意圖進行推理的方法，而不只是操作參數。沒有任何掃描器能可靠地取代了解各使用者角色應該與不應該能存取哪些內容的測試人員。

應用程式安全測試工具

像 OWASP ZAP 和 Burp Suite 這類 DAST 工具，在設定多使用者測試帳號與跨使用者物件 ID 對應時，可以找出 IDOR。預設的掃描器設定不會顯示出 IDOR。SAST 工具可以標示缺少授權函式呼叫的端點，但無法判定授權邏輯在執行階段是否在語意上正確。

執行階段行為監控

這是唯一能在正式環境中實際找出 IDOR 的正式環境控制。請尋找以下訊號：

• 來自單一工作階段、對物件參考端點發出的連續或列舉模式請求
• 已驗證身分的請求對不屬於請求使用者的物件 ID 回傳 200 OK
• 跨多個使用者帳號的大量物件參考請求

不同於部署前測試，行為監控 會在正式環境中持續運作，而真正的利用行為正是在那裡發生。這是唯一能捕捉到 IDOR 正在對即時資料遭到主動濫用的控制措施。

安全程式碼審查

根據 Authorization cheat sheet，程式碼審查必須驗證每個請求都會驗證權限，且 存取控制 是以全域方式實作，而非逐一方法實作。請特別注意接受使用者提供識別碼的端點，並追蹤從參數輸入、資料庫查詢到回應的程式碼路徑。任何在未將查詢範圍限制於已驗證使用者權限的情況下擷取物件的路徑，都代表已確認的 IDOR 風險。

找出 IDOR 只是第一步。要防止它，必須在整個開發與部署生命週期中嵌入控制措施。

如何防止不安全的直接物件參考

預防需要涵蓋設計、開發、測試與執行階段監控的分層方法。

設計階段：將授權建模納入每項功能

在功能設計期間，將失效的存取控制納入您的 攻擊面分析。在撰寫程式碼之前，先定義明確的授權函式（canAccess, isOwner 模式）。

開發階段：對每次物件存取強制執行伺服器端授權

The IDOR cheat sheet 指定了以下控制措施：

1. 對使用者嘗試存取的每個物件實作存取控制檢查。 從工作階段資訊而非用戶端提供的識別碼判定已驗證的使用者。透過集中式中介軟體強制執行檢查，而非依賴逐一方法邏輯。
2. 將資料庫查詢範圍限定於已驗證使用者可存取的資料集：

3. 使用間接參照對應表，將混淆的外部值轉換為內部資料庫 ID，並結合授權檢查。

4. 採用 UUID 或長隨機值 作為對外公開的識別碼。這是縱深防禦層，而非主要控制措施。

5. 避免對識別碼進行加密。 OWASP Cheat Sheet 指出，這「可能難以安全地實作。」

6. 對靜態資源強制執行授權，根據 授權速查表，這是經常被忽略的攻擊面。

這些控制措施之所以有效，是因為它們在資料層強制執行擁有權，而不是信任用戶端提供的值。攻擊者若操縱參數，遭遇的會是授權檢查，而不是成功的查詢。

測試階段：多使用者授權測試

執行採用多使用者組態的 DAST 掃描，以測試跨帳戶存取。納入可標記缺少授權函式呼叫之端點的 SAST 規則。優先進行手動滲透測試，以檢測業務邏輯 IDOR。

執行階段：API 行為監控

部署行為監控，建立正常 API 存取模式的基準，並標記異常的物件存取。SentinelOne 的 Storyline 技術可重建 API 互動的完整序列，以及可疑存取模式周圍的身分內容，為您的團隊提供確認或排除 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 功能（您可以執行哪些操作），主要會導致垂直權限提升。
• Forced Browsing (CWE-425). 繞過導覽與頁面層級控制，直接存取受限頁面，被列為一個具體的 Broken Access Control 範例。
• SQL Primary Key Authorization Bypass (CWE-566). 作為 CWE-639 的直接子項，這是以 SQL 為後端的 IDOR 實作最具體的 CWE。
• Vertical Privilege Escalation (CWE-269 / CWE-285). 當攻擊者修改識別碼以存取管理功能時，IDOR 可串連成 privilege escalation，如 Honda eCommerce 案例所示。

數個具體的 CVE 展示了這些相關弱點模式如何出現在正式環境系統中。

相關 CVE

Unleash AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

結論

不安全的直接物件參照仍然是最常遭到利用的 Web 安全失敗之一，因為它破壞的是物件層級授權，而不只是輸入處理。如果您的應用程式信任使用者提供的識別碼而不檢查擁有權，URL 的微小變更就可能演變成大規模資料暴露。 

您可以透過在每次物件存取時強制執行授權、跨多個使用者情境進行測試，以及在正式環境中監控濫用行為來降低該風險。