Insecure Direct Object reference (IDOR) is a type of access control vulnerability that arises when an application uses user-supplied input to access objects or functions directly. IDOR can also be reported as Broken Access Control and as BOLA (Broken Object Level Authorization) or BFLA (Broken Function Level Authorization) for APIs. Some of the steps to find such vulnerabilities are:

1. Create 2 test accounts.
2. Explore all endpoints and functionalities with one account.
3. Test all authenticated requests without credentials to see if they work.
4. If the token can be forged, try all requests of the app with an inexistent user id to see what he is able to do.
5. Look for information disclosure of PII (personally identifiable information) that might help in the next steps.
6. Use the Autorize Burp extension to test admin endpoints with an unprivileged user or from another user with the same privileges.
7. Check if you can assess endpoints from other users with the same or more privileges with your credentials. Fuzz ids where applicable. In bug bounty programs use the ID from a 2nd test account and don't fuzz. Do not forget to also analyse Headers (e.g. the Referer and X-Origin-URL) from the requests made by the admin when comparing them with the ones from an unprivileged user, they might be different and affect the functionality.
8. Check functionality from other users with the same or more privileges with your credentials.