Threats, Vulnerabilities, and Mitigations →mediumMultiple ChoiceObjective-mapped

SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

A file-sharing portal uses a download URL like /download?file=12345. A tester changes the value to 12346 and can access another department's document without logging in again. Which control most directly prevents this issue?

⚠ Common exam trap

Many exam-takers confuse confidentiality controls (like HTTPS or longer identifiers) with authorization controls, failing to recognize that the core flaw is the lack of server-side permission verification for each object request.

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

✓

Implement server-side authorization checks for every object request.

The issue is that the server trusts the file identifier in the URL without verifying that the authenticated user is authorized to access the requested resource. Implementing server-side authorization checks for every object request ensures that before serving any file, the server validates whether the current session or user has explicit permission to access that specific document. This directly prevents the IDOR (Insecure Direct Object Reference) vulnerability demonstrated by the tester.

Answer analysis

Option-by-option breakdown

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

✓
Implement server-side authorization checks for every object request.
Why this is correct
Server-side authorization ensures the application verifies that the current user is allowed to access the specific object requested. This directly stops insecure direct object reference issues because changing the identifier alone no longer grants access. The check must happen on the server for every request, not in the browser.
✗
Make the identifier longer so users cannot guess nearby values.
Why it's wrong here
Lengthening identifiers, such as switching to UUIDs, reduces the chance of random guessing or enumeration attacks, but this is security through obscurity rather than a real control. It does not add any authorization logic, so if a user obtains a valid identifier through shared links, logs, or cache entries, they can still access the object without permission. The underlying IDOR flaw is missing access control; increasing entropy only makes discovery harder, it never substitutes for a server-side permission check.
✗
Move the portal to HTTPS so request parameters cannot be intercepted.
Why it's wrong here
HTTPS protects the confidentiality and integrity of data in transit, preventing passive eavesdroppers from reading identifiers in URLs or request bodies. However, the typical attacker in an IDOR scenario is an already authenticated user of the portal who is simply manipulating parameters to access resources they are not entitled to. Since HTTPS does not inspect or authorize requests, an authenticated user can still change an object ID and receive the response; the access control decision is never made, so the vulnerability remains fully exploitable.
✗
Store the document name in a hidden field and validate it in JavaScript.
Why it's wrong here
Hidden fields and JavaScript validation run entirely in the client environment, which the attacker controls. A user can use browser developer tools to alter the hidden field value, disable the script, or craft a raw HTTP request that bypasses the client-side checks altogether. Authorization must be enforced on the server, where the decision cannot be tampered with; client-side validation only creates a false sense of security and does not mitigate the IDOR at all.

Go deeper

SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question