hunt-idor

Create two accounts at the same privilege level, capture User A's resource IDs while authenticated, then replay those requests with User B's session token. Test all HTTP verbs (GET, POST, PUT, PATCH, DELETE) and confirm a 200 response containing User A's data instead of a 403 or 404.

IDOR and BOLA (Broken Object Level Authorization, OWASP API Top 10 A1) both mean accessing objects belonging to other users. BFLA (Broken Function Level Authorization) means a low-privilege user accessing high-privilege functions like admin endpoints or bulk operations.

Yes. GraphQL resolvers often fetch objects by ID without field-level authorization checks. Run introspection to enumerate queries and mutations accepting id arguments, then substitute another user's ID in both queries and mutations, including Relay-style node(id:) global IDs.

UUIDs frequently leak in other API responses, notification emails, webhooks, JavaScript bundles, or GraphQL queries. Harvest victim UUIDs from accessible endpoints, then replay them against restricted endpoints that only check authentication rather than ownership.

The most common cause is a 200 response that returns no actual victim data, such as empty arrays, redacted fields, or an access-denied message in the body. Always confirm the response contains the victim's real data and demonstrate reproducibility with two fresh accounts.

Chain when a read-only IDOR can reach a state-changing endpoint sharing the same ID, such as email change leading to account takeover, refund endpoints causing financial loss, or member-add endpoints enabling role escalation. Chained IDORs typically receive significantly higher bounty payouts.