Insecure Direct Object Reference (IDOR) occurs when an application exposes internal implementation objects (e.g., database keys, filenames, or record IDs) and allows users to directly manipulate or access them without proper authorisation checks. An adversary can exploit this by guessing or modifying identifiers in requests (such as changing `user_id=123` to `user_id=124`) to gain unauthorised access to sensitive data or perform actions on behalf of other users.

Remediation

• Avoid exposing sensitive internal resources via identifiers; where possible, resolve objects server-side based on the authenticated user’s session or context.
• Do not rely on predictable or sequential identifiers (e.g., auto-incrementing IDs, guessable strings).
• Enforce strict server-side authorisation checks on every request to ensure users can only access resources they are explicitly permitted to.
• Use indirect object references (e.g., opaque, randomised tokens or UUIDs) in place of raw identifiers exposed to clients.
• Apply logging and monitoring to detect suspicious access patterns that may indicate IDOR exploitation.