AI-Generated IDOR (Broken Object-Level Authorization) Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that looks up, updates, deletes, or exports an object using an identifier supplied by the request. The goal is to stop a generated endpoint from shipping with a working happy path for the requester's own data while quietly allowing access to anyone else's data by changing an ID.

This is a review policy, not an IDOR tutorial. It tells reviewers what must be true about a generated change's authorization checks and lookup pattern before the change is safe to merge.

Review Inputs

Collect enough context to know what object is being accessed and who should be allowed to access it.

• Every route, resolver, or RPC method the change adds or edits that accepts an object identifier from a URL path, query string, request body, or header.
• What kind of object each identifier refers to (single-owner, shared among a team, or globally readable) and who is allowed to read, write, or delete it.
• How the handler currently looks the object up: a scoped query tied to the current user, or a global lookup by primary key/slug.
• Whether sibling routes in the same area already enforce authorization through a shared middleware, guard, or policy object.

Object-Level Authorization Rules

• Every operation that resolves an object from a request-supplied identifier must verify, server-side, that the current user is allowed to access that specific object — authentication alone (proving who the user is) is not authorization (proving what they may access).
• Prefer scoped lookups that can only ever return objects the current user owns or has been granted access to, over a global lookup followed by a separate permission check that is easy to omit or get out of sync.
• Derive the acting user from server-side session or token state, never from a client-supplied field such as a hidden user_id, an ownerId in the request body, or a bearer claim the client can influence.
• Apply the same check to every verb and variant on the object: read, update, delete, export/download, bulk operations, and admin-only variants each need their own enforcement, not just the primary read path.
• For nested or related objects (a comment on someone else's document, a line item on someone else's order), verify authorization on the parent object as well as the child, not just the child's own ID.

Identifier And Lookup Rules

• Treat any identifier accepted from the client (URL, query, body, or header) as untrusted input to a lookup, not as proof of entitlement.
• Where practical, avoid exposing sequential or otherwise guessable identifiers in URLs and forms; prefer non-enumerable identifiers (UUIDs, random tokens) as a defense-in-depth measure.
• Do not rely on identifier complexity alone: an attacker who obtains or is given a valid but unauthorized ID (via a shared link, referrer leak, or another vulnerability) must still be denied by the authorization check.
• For multi-step flows, keep the object reference in server-side session state rather than round-tripping it through client-editable form fields across steps.
• When adding a new data-access function, check whether an existing scoped query helper for that model already exists before writing a new global lookup.

Merge Blockers

Block merge when any of these is true.

• An endpoint resolves an object by a request-supplied identifier without a server-side check that the current user may access that specific object.
• Authorization is enforced on the read path for an object but not on its update, delete, export, or admin variant.
• The acting user or their permissions are taken from a client-supplied field (hidden form value, request body user_id, editable claim) instead of server-side session/auth state.
• A new route bypasses a shared authorization middleware/guard/policy that equivalent existing routes use, without a documented reason.
• Non-guessable identifiers (UUIDs, tokens) are treated as the sole protection for an object, with no actual authorization check behind them.

Review Checklist

• {"task": "Object-level check present", "description": "Every request-supplied identifier lookup is followed by a check that the current user may access that specific object"}
• {"task": "Scoped lookup preferred", "description": "Data access goes through a query scoped to the current user/tenant rather than a global lookup plus an afterthought check"}
• {"task": "All operations covered", "description": "Read, update, delete, export, and admin/bulk variants all enforce the same authorization, not just the primary read path"}
• {"task": "Server-side identity", "description": "The acting user is derived from session/auth state, never a client-supplied user/owner field"}
• {"task": "Nested objects checked", "description": "Authorization is verified on parent objects, not just the child object's own identifier"}
• {"task": "No false sense of security", "description": "Unguessable identifiers are not treated as a substitute for an actual authorization check"}

AI Review Rules

AI assistants can write and review data-access code, but they should show their evidence.

• Ask the assistant to list every route or resolver in the change that accepts an object identifier from the request, and how each one is authorized.
• Require the assistant to state whether each lookup is scoped to the current user or is a global lookup, and if global, where the permission check happens.
• Have the assistant confirm write, delete, export, and admin variants were checked, not only the read path it may have tested first.
• Do not let the assistant claim a UUID or random identifier makes the endpoint safe without a server-side authorization check.
• Re-run review after any change to routing, the permission model, or shared authorization middleware.

Troubleshooting

• A legitimate cross-team share stops working after adding the check: the object likely needs an explicit shared-access grant (a membership or ACL entry) rather than being reachable by anyone who has the ID; model the sharing relationship instead of loosening the check.
• The scoped query returns nothing for an object the user should see: confirm the scoping relation actually includes shared/team-owned objects, not only objects the user directly created.
• Tests pass but only exercise the requester's own data: add a second test account and assert that it is denied access to the first account's objects across read, write, and delete.
• An admin panel needs to bypass per-user scoping: give it its own explicit admin-authorization check rather than removing scoping from the underlying data-access function that regular routes also call.

Duplicate And History Check

Before adding a new authorization check, confirm the codebase does not already have a shared scoping helper, policy object, or middleware for this model. A generated route that writes its own inline permission check next to an existing shared guard should be treated as suspicious — check whether the existing mechanism was simply not reused before introducing a second, parallel, and possibly inconsistent one.

Reference

Sources

• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP REST Security Cheat Sheet
• OWASP API Security Top 10: Broken Object Level Authorization
• CWE-639: Authorization Bypass Through User-Controlled Key

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15