<aside> ❓ What if I told you that there is a web application vulnerability so simple to exploit, that it could make bug hunting feel like a breeze?

</aside>

https://www.youtube.com/watch?v=EQ7QdlXV6fo

<aside> 💡 Insecure Direct Object References (IDOR) is a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly.

</aside>

Tips

1. Parameters

Top IDOR parameters to look out for

id=
uid=
gid=
user=
account=
number=
order=
no=
doc=
file=
key=
email=
group=
profile=
edit=
report=

2. UUIDs

UUIDs are Universally Unique Identifiers, and you will encounter them often when hunting for IDORs. They are designed to be non-guessable, which might seem to shut down avenues for exploitation. Many bug bounty programs do not consider IDORs on UUIDs.

But don’t be deterred; here are a few tricks to test these seemingly secure IDs

  1. Look for Leaks.UUIDs can sometimes be exposed in other parts of the application. Check logs, error messages, and the page source.
  2. Don’t assume all UUIDs are created perfectly. Test if they are truly non-guessable. Sometimes, developers implement custom UUID generation methods that may not be as random as expected.
  3. Try simpler modifications. Replace a complex UUID in the URL with basic numeric sequences or predictable patterns like 0000000-0000-0000-000000000000. You’d be surprised how often the default values are overlooked in access controls.
  4. Dig in the archives. Utilize tools like the Wayback Machine or Common Crawl. These archives might hold versions of the application where UUIDs were exposed.

3. Parameter Pollution

Consider the following enpoint:

/api/messages?user_id=<USER_ID>

If you can’t find an IDOR on the user_id parameter, try to add another user_id .

/api/messages?user_id=<USER_ID>&**user_id=<OTHER_ID>**

Another variation involves lists.