用途：审计并修复 Web 应用中的访问控制缺口，目标是确保每个路由都校验“谁能访问哪一个具体资源”，而不仅是“是否已登录”。核心区分：认证回答“你是否已登录”（身份）；授权回答“你能否访问这条记录”（权限）。多数认证中间件只处理前者，后者必须按端点、按资源逐一落实。
主要覆盖的漏洞模式：IDOR（用户自带 ID 被直接按 ID 查询，未校验归属）；缺少角色校验；通过用户自传 role/plan/credits 等字段造成权限提升；同一路由仅某个 HTTP 方法受保护、其他方法可绕过；URL 参数与 JWT 身份不一致；嵌套子资源只校验子资源归属、未校验父资源；多租户应用只按用户范围查询、缺少 tenant 范围。对应修复要点：查询中始终带上 owner_id = req.user.id 或等价条件，不要只按 ID 查；写接口使用字段白名单，不把 req.body 直接交给 ORM；多租户时 tenant_id 必须来自令牌而非请求；每个 HTTP 动词独立加门。
授权模型：RBAC（基于角色）、ABAC（基于属性）、Ownership（归属）、ReBAC（基于关系）。多数应用需要 Ownership 与 RBAC 组合：用户数据用归属，管理面用角色。
审计流程：一，列出全部端点及 HTTP 动词，标出无认证中间件的路由；二，按资源类型确定所需检查（自有资源、管理操作、组织共享、公开读）；三，检查查询是否在 WHERE 中直接强制归属/租户范围，而非先取后判；四，检查写路径字段白名单；五，检查以 email、用户名、slug 等间接引用作为键的端点，同样应用归属校验。响应码建议：未登录 401；已登录但权限不足 403；资源存在但调用者不应知晓用 404，避免泄露记录存在性。资料还附有 references/models.md 与 references/testing.md 参考文件。
限制：此为技能说明，未提供具体安装命令、依赖、平台支持范围或价格信息，使用前需结合自身技术栈自行适配。