IDOR（存取控制缺陷）是指把 URL 裡的 id=124 改成 125，就會顯示出他人發票的漏洞。本文講解其原理與可靠的防範方法（不會寫出攻擊步驟）。
為什麼會發生
明明「認證（你是誰）」已經通過，卻缺了「授權（這個人是否可以操作它）」時就會發生。認證與授權是兩回事，能登入並不等於可以查看那份資料。
| 常見的疏漏 | 後果 |
|---|---|
| 登入後就直接信任 ID | 改成他人的 ID 就能存取成功 |
| 誤以為「介面上不顯示＝安全」 | 直接呼叫 API 時不會被擋下 |
| 建立/更新/刪除沒有權限校驗 | 不僅能查看，還能竄改、刪除 |
為什麼會成立（原理）
ID 不只出現在 URL 的 ?id= 中。API 路徑（/api/orders/125）、JSON 本文（"userId": 125）、檔案下載 URL 與表單的隱藏欄位，都需要同樣的檢查——凡是由使用者送來的值決定要操作哪個物件的地方都是。
相關用語
IDOR 是存取控制缺陷的一種形式。它有好幾個名稱，也容易與鄰近的概念混淆。
| 用語 | 缺少的是什麼 | 例子 |
|---|---|---|
| IDOR | 針對每個物件的擁有者與權限檢查 | 使用者 A 改了 ID 就看到使用者 B 的發票 |
| BOLA | 與 IDOR 相同（OWASP API Security 的名稱） | API 的 /orders/{id} 回傳了別人的訂單 |
| 功能層級授權缺陷 | 針對每個功能的權限檢查 | 一般使用者能呼叫管理員專用的 API |
| 認證缺陷 | 「你是誰」的檢查本身 | 不登入也能呼叫 API |
在 OWASP Top 10 中，存取控制缺陷（A01）在 2025 年版與 2021 年版一樣排名第一。在以 API 為對象的 OWASP API Security Top 10（2023）中，BOLA 同樣排名第一（API1:2023）。
實際案例：登入後能看到他人的資料
本站介紹過的兩起公部門案例，官方都歸因於系統更新時引入的缺陷，但結果與授權缺陷的形態相同：已登入的使用者能觸及不屬於自己的資料。
- 英國 Companies House（2026 年 3 月）：登入 WebFiling 的使用者，透過特定操作可能看到其他公司董事的住家地址等資訊，技術上也可能進行未經授權的申報。該機構表示這是 2025 年 10 月系統更新所引入的缺陷，而非外部攻擊 → 詳細解說（英文）
- 日本國稅廳 e-Tax（2026 年 9 月）：「我的頁面」更新造成的缺陷，讓其他使用者能查看 79 人的贈與稅申報書等文件 → 詳細解說（英文）
兩起案例中，登入檢查都正常運作。缺少的是「這個使用者是否可以操作這個物件」。而且兩起都發生在變更之後。即使原本做對了，新增功能時也可能失去檢查，所以每次都會執行的自動化測試很有價值。
防禦：在伺服器端每次確認「擁有者與權限」
針對每個物件校驗擁有者與權限（最重要）
在回傳/變更資料的緊前一刻，必須在伺服器端校驗「目前登入的使用者 ID，是否為該物件的擁有者、是否擁有操作權限」。不滿足則拒絕。
預設拒絕（deny by default）
新的端點應以「除明確許可的條件外一律拒絕」為初始狀態，讓漏加校驗時倒向「拒絕」一側，而非「放行」一側。
只查詢「屬於自己的」物件
在查詢語句本身中就帶上擁有者條件（例如：使用者 ID＝本人 來篩選）。統一走全應用程式通用的授權輔助函式，杜絕各處的遺漏。
不要把介面控制誤當成防禦
隱藏/不顯示按鈕屬於 UX，而非防禦。要以「API 會被直接呼叫」為前提，只在伺服器端做判斷。隨機 ID 只能作為輔助。
如何檢查自己的 App
只在你自己開發或管理的 App 中進行。在他人的服務上嘗試，可能構成未經授權的存取。
- 建立測試使用者 A 與 B，各給一筆資料（訂單、檔案等）
- 以 A 登入，用指向 B 那筆資料的 ID 呼叫查看、更新與刪除的 API。不經由介面，而是用開發人員工具或 API 用戶端直接呼叫
- 確認每個請求都以 403 或 404 被拒絕。也要確認列表端點不會包含 B 的資料
- 把這些變成自動化測試，每新增一個端點就加上同樣的測試
OWASP API Security Top 10 同樣建議撰寫評估授權機制的測試，並且不要部署會讓這些測試失敗的變更。
本站的觀點：容易被忽略但影響很大，用自動化測試來檢查
IDOR 在技術上很樸素，連程式碼審查也容易漏看。然而「一次點擊就能看到他人全部個人資訊」這類危害非常嚴重。正因如此，加入「用另一個使用者去存取他人的 ID，必須回傳 403」的自動化測試才是實際可行的做法。本站堅持「不靠用戶端的外觀來防守／只在伺服器端做判斷」的原則。授權是「靠機制每次都生效」的東西，關鍵在於不依賴人的注意力。
出處（一手資料）
- OWASP Top 10:2025, "A01 Broken Access Control" — top10.owasp.org（排名；不安全的直接物件參照的例子）
- OWASP API Security Top 10 2023, "API1:2023 Broken Object Level Authorization" — api-security.owasp.org（預防方式；測試的建議）
- MITRE CWE-639: Authorization Bypass Through User-Controlled Key — cwe.mitre.org
- 兩起案例的出處（Companies House 與國稅廳的公告）列在各案例的解說中
接下來閱讀
- 學習：身分驗證與授權的差別（登入 ≠ 授權；IDOR 就是這種「授權缺失」的一種形式）
- 案例：Companies House WebFiling 的缺陷（英文） · e-Tax 贈與稅申報書可被其他使用者查看（英文）
- 術語：CSRF 是什麼（濫用你已登入狀態的攻擊） / OWASP Top 10 是什麼 / 工作階段固定是什麼
- 入門：安全超入門 / 免費安全工具