Insecure direct object reference is a type of vulnerability where the application does not verify if the user is authorized to access the internal object via its name or key. Suppose a malicious…

Question

Options

• A"GET /restricted/goldtransfer?to=Rob&from=1 or 1=1' HTTP/1.1Host: westbank.com"
• B"GET /restricted/\r\n%00account%00Ned%00access HTTP/1.1 Host: westbank.com"
• C"GET /restricted/accounts/?name=Ned HTTP/1.1 Host westbank.com"
• D"GET /restricted/ HTTP/1.1 Host: westbank.com

• A
  7% (3)
• B
  18% (8)
• C
  71% (32)
• D
  4% (2)

Explanation

Explanation

Option C demonstrates a classic Insecure Direct Object Reference (IDOR) attack because Rob is directly referencing Ned's account object by name (?name=Ned) in the URL, attempting to access Ned's data without any indication that the application has verified Rob's authorization to do so - the application simply trusts the user-supplied identifier to retrieve the internal object.

Why the distractors are wrong:

• Option A contains 1 or 1=1', which is a SQL injection payload, not an IDOR exploit
• Option B uses encoded null bytes (%00) and carriage returns (\r\n), which resembles a null byte injection or path traversal attack
• Option D is simply a request to a restricted directory with no object reference manipulation, more akin to unauthorized access/forced browsing

Memory Tip: Think of IDOR as "name-dropping" - the attacker directly names someone else's resource (like ?name=Ned or ?id=456) in the request, with the vulnerability being that the app fetches it without checking who's asking. If the request contains another user's identifier being passed as a parameter, that's your IDOR red flag.

No community discussion yet for this question.