GCIH Exploiting Insecure Web App References Practice Question
A financial services company is hardening a REST API that returns account statements. Each request includes a numeric `accountId`, and the API currently returns the statement whenever the `accountId` exists. The security team wants to close the insecure direct object reference exposure without redesigning the data model. Which two controls, applied together, most directly address the flaw? (Choose two.)
⚠ Common exam trap
The trap here is treating identifier randomization or transport security as an authorization control, when neither prevents an authenticated user from naming and retrieving an object they do not own.
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
✓
Derive the account identifier from the authenticated session context instead of trusting the client-supplied `accountId`.
The exposure exists because the API trusts a client-supplied identifier and never checks entitlement. Binding the account to the authenticated session removes the attacker's ability to name arbitrary objects, and an explicit ownership or delegation check catches legitimate cases where identifiers must be supplied. Together these enforce object-level authorization on every request, which is the durable fix for insecure direct object references.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the account identifier length from six digits to a random 128-bit value so that account numbers cannot be enumerated.
Why it's wrong here
Randomizing identifiers raises the effort for guessing but does not authorize the request. Identifiers leak through statements, emails, support tickets, and logs, and an attacker holding a valid value can still retrieve another customer's data. Because no ownership check is added, the reference remains a bearer credential. This is obfuscation, not an access control.
- ✗
Require TLS 1.3 with mutual authentication between the mobile client and the API gateway for every statement request.
Why it's wrong here
Transport hardening protects data in transit and authenticates the client application, but it does not distinguish one customer from another. A malicious authenticated customer using the legitimate app still passes mutual TLS and can request arbitrary account numbers. The flaw lives in object-level authorization, which transport controls do not influence, so this does not mitigate the exposure.
- ✓
Derive the account identifier from the authenticated session context instead of trusting the client-supplied `accountId`.
Why this is correct
When the server resolves the account from the session rather than the request body or query string, the client cannot name an object it does not own. This removes the attacker's ability to substitute another account number. It is a direct structural fix for the reference flaw because the object selection is bound to the authenticated principal before any data is returned.
- ✓
After resolving the requested account, verify that the authenticated user is an owner or authorized delegate of that account before returning the statement.
Why this is correct
Even when a client-supplied identifier is accepted, an explicit ownership or delegation check ensures the principal is entitled to the object. This catches cases where the identifier is legitimately needed, such as shared accounts, and it fails closed when the relationship is absent. It is the canonical server-side authorization gate that prevents horizontal privilege escalation.
- ✗
Log every statement request with the account identifier and alert when a single session requests more than one distinct account.
Why it's wrong here
Detection is valuable for incident response, but it does not prevent the unauthorized disclosure. By the time the alert fires, statements have already been returned. Logging and alerting complement authorization controls rather than replacing them, and a patient attacker requesting one account per session would never trigger the threshold. This addresses visibility, not the underlying reference weakness.
About these practice questions
This GCIH question is part of Courseiva's 322-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCIH practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCIH exam.