CEH Web Application and Injection Attacks Practice Question

During a penetration test, a security analyst discovers that a web application uses sequential numeric identifiers in URLs (e.g., /profile?id=100). By modifying the id parameter, the analyst can access another user's profile data without authorization. Which vulnerability is being exploited?

⚠ Common exam trap

The trap is confusing IDOR with CSRF or SSRF because all involve manipulating requests, but IDOR specifically hinges on unauthorized access to an object via a client-controlled identifier.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR) occurs when an application exposes an internal object identifier, such as a numeric id in a URL, and fails to verify that the requester is authorized to access that object. Changing the id to another user's value and retrieving their data is the classic IDOR exploitation pattern.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
SQL injection
Why it's wrong here
SQL injection exploits vulnerabilities where user input is directly incorporated into SQL queries without proper sanitization or parameterization. This allows an attacker to inject malicious SQL commands, potentially bypassing authentication, extracting sensitive database information, or even modifying data. Unlike IDOR, SQL injection targets the database layer directly through query manipulation, rather than manipulating application-level object identifiers.
✓
Insecure Direct Object Reference (IDOR)
Why this is correct
Insecure Direct Object Reference (IDOR) occurs when an application exposes a direct reference to an internal implementation object, such as a file, directory, or database record, and fails to implement sufficient authorization checks. By manipulating parameters like 'id' in a URL or API request, an attacker can bypass authorization and access resources belonging to other users or system components. This direct manipulation of object identifiers to gain unauthorized access perfectly describes the scenario where changing an 'id' parameter reveals another user's data.
✗
Server-Side Request Forgery (SSRF)
Why it's wrong here
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This allows the attacker to force the server to connect to internal services within the organization's infrastructure or to external third-party systems. SSRF does not involve directly manipulating user-facing object identifiers to access different data, but rather leverages the server's network access to probe or interact with other systems.
✗
Cross-Site Request Forgery (CSRF)
Why it's wrong here
Cross-Site Request Forgery (CSRF) is an attack that tricks a victim into submitting a malicious request to a web application in which they are currently authenticated. The attacker crafts a malicious web page or email that, when visited by the victim, causes their browser to send an authenticated request to the target site without their explicit knowledge or consent. This differs significantly from IDOR, as CSRF relies on the victim's browser and active session to perform actions, rather than the attacker directly altering object references.

Go deeper

CEH Web Application and Injection Attacks Practice Question

Why each option matters

Option-by-option breakdown

Related to this question