用途：识别并修复 IDOR 漏洞。IDOR 指 URL 或请求体中的 ID 直接映射到数据库记录且缺少归属校验，攻击者通过递增参数即可读取他人数据。
主要能力与要求：
- 不可猜测 ID：将自增、短哈希等可猜测 ID 替换为 UUIDv4、ULID/UUIDv7 或 CUID2。Postgres 可用 gen_random_uuid() 作为默认值。可保留内部数字主键用于连接和索引，仅对外暴露 UUID。
- 归属校验：所有查询都必须限定到已认证调用者，不能仅按 ID 查询；owner_id 必须来自 JWT，不能来自请求体或查询参数。未授权访问返回 404 而非 403，避免泄露资源存在性。
需检查的隐蔽模式：邮箱或用户名查找、按文件名下载文件、写路径（POST/PUT/PATCH/DELETE）、嵌套资源需先校验父资源归属、批量操作需限定 owner、多租户场景还需加入 tenant_id 限定。
迁移步骤：新增 public_id 列并填充、设为非空并建唯一索引；保留内部 id 维护外键完整性；API 响应只暴露 public_id，输入只接受 public_id，由服务端转换为内部 id。
审计清单：对外 ID 均不可顺序猜测；每个 findById/findOne/update/delete 含 owner_id 或 tenant_id 限定；写路径同样校验归属；嵌套路由先校验父资源；批量操作限定 owner；文件端点按名称加归属查找；未授权返回 404；owner_id 与 tenant_id 均取自 JWT。
限制：资料未提供具体运行平台、安装命令、价格或效果数据，暂未提供。