跳到正文
ITDWeb 安全平台
ITD
搜索

术语表

#IDOR#访问控制#漏洞

IDOR 是什么：改写 ID 就会暴露他人数据的漏洞

IDOR（访问控制缺陷）是只要改写 URL 或参数中的 ID，就能访问他人数据的漏洞。图解原理，并讲解主要防御：在服务端每次确认该用户是否有权查看该对象。

发布于 2026-06-10 更新于 2026-10-06 2 分钟阅读
本页目录

IDOR（访问控制缺陷）是指把 URL 里的 id=124 改成 125，就显示出了他人的发票。本文讲解其原理与可靠的防范方法（不会写出攻击步骤）。

为什么会发生

明明「认证（你是谁）」已经通过，却缺了「授权（这个人是否可以操作它）」时就会发生。认证与授权是两回事，能登录并不等于可以查看那份数据。

常见的疏漏后果
登录后就直接信任 ID改成他人的 ID 就能访问成功
误以为「界面上不显示＝安全」直接调用 API 时不会被拦下
创建/更新/删除没有权限校验不仅能查看，还能篡改、删除

为什么会成立（原理）

用户 A 登录 → 自己的发票 /invoice?id=124
把 id 改成 125（用户 B 的）
↓ 服务端只看到「125 是存在的」
因为没有所有者校验，于是显示出了他人的发票
只看 ID 的「形式」而不确认所有者，那么仅靠把自己的 ID 改成他人的 ID 就能通过。

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 人的赠与税申报书及相关文件 → 详细解说

在这两起案例中，登录校验都是正常的。缺少的是「这个用户是否可以操作这个对象」。而且两者都发生在变更之后。即使当初构建得正确，增加功能时校验也可能丢失，因此值得准备一套每次都会运行的自动化测试。

防御：在服务端每次确认「所有者与权限」

1

针对每个对象校验所有者与权限（最重要）

在返回/变更数据的紧前一刻，必须在服务端校验「当前登录的用户 ID，是否为该对象的所有者、是否拥有操作权限」。不满足则拒绝。

2

默认拒绝（deny by default）

新的端点应以「除明确许可的条件外一律拒绝」为初始状态，让漏加校验时倒向「拒绝」一侧，而非「放行」一侧。

3

只查询「属于自己的」对象

在查询语句本身中就带上所有者条件（例如：用户 ID＝本人 来筛选）。统一走全应用通用的授权辅助函数，杜绝各处的遗漏。

4

不要把界面控制误当成防御

隐藏/不显示按钮属于 UX，而非防御。要以「API 会被直接调用」为前提，只在服务端做判断。随机 ID 只能作为辅助。

检查自己应用的方法

只在你自己开发或管理的应用中进行。对他人的服务这样尝试，可能构成未经授权的访问。

  1. 创建测试用户 A 和 B，并各自给一条记录（订单、文件等）
  2. 以 A 登录，用指向 B 记录的 ID 调用查看、更新、删除的 API。不要经由界面，而是从开发者工具或 API 客户端直接调用
  3. 确认所有请求都以 403 或 404 被拒绝。同时确认列表类端点中不包含 B 的记录
  4. 把这些写成自动化测试，每次新增端点时都追加同样的测试

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 与国税厅的公告）列在各自的案例解说中

接下来阅读

分类编号

CWE 对导致漏洞的弱点类型进行分类，MITRE ATT&CK 对攻击者的技术进行分类。两者均由 MITRE 维护，广泛用于标注漏洞信息和检测规则。

CWE（弱点类型）

CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use

FAQ

QIDOR 会发生什么？
A

已登录的用户，仅靠把 URL 或 API 中的 ID（如 ?id=124）改成另一个值，就能查看、修改、删除他人的发票、订单、个人信息、文件等。它是 OWASP 中最常见的问题类别（访问控制缺陷）的典型例子，可怕之处在于无需任何特殊工具就能发生。

Q最主要的防御是什么？
A

就是「在服务端每次确认『当前登录的这个用户，是否可以操作该对象』」。即使 ID 形式正确，也必须校验它是否为本人所有、是否拥有权限，不满足则拒绝（默认拒绝）。绝不能只依赖客户端的界面控制。

Q把 ID 改成 UUID 或随机值就能防住吗？
A

那只是让它更难猜，并不能修复漏洞。一旦 ID 被泄露或被分享出去，请求依然会成功。随机化只能作为辅助，主要的防御一定是服务端的所有者与权限校验。

QIDOR 和 BOLA 有什么区别？
A

两者指的是同一个问题。IDOR 是 Web 应用中沿用已久的名称；BOLA（Broken Object Level Authorization，对象级授权缺陷）是 OWASP API Security Top 10 中使用的名称，在 2023 年版中排名第一（API1:2023）。两者都表示缺少针对每个对象的授权校验。

Q如何测试自己的应用是否存在 IDOR？
A

在自己的应用中创建 A、B 两个测试用户。以 A 登录，用 ID 请求查看、更新、删除 B 的数据，确认所有请求都被拒绝（403 或 404）。不要经由界面，而要直接调用 API，并把这项检查保留为自动化测试。

QIDOR 在 OWASP Top 10 中处于什么位置？
A

属于 A01「访问控制缺陷（Broken Access Control）」。它在 2021 年版和 2025 年版中都排名第一，OWASP 还把「只要提供唯一标识符就能查看或编辑他人账户（不安全的直接对象引用）」列为示例。