GCIH Web App API Attacks Practice Question
A SOC analyst triages an alert showing that a mobile banking API responded to a request for /api/accounts/8842/transactions with HTTP 200 and another customer's transaction list. The requesting user was authenticated normally with a valid session token, but the account number in the URL belonged to a different customer. The API returned data without checking whether the authenticated user owned that account. Which vulnerability does this represent?
⚠ Common exam trap
The trap here is treating a valid authenticated session as sufficient authorization, when the missing ownership check on the object is the actual flaw.
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
✓
Broken object level authorization on the account resource
The caller was properly authenticated, but the API failed to confirm that the authenticated identity owned the account referenced in the URL. Authorization must be evaluated per object on every request, comparing the resource's owner against the caller's identity. Relying on a valid session alone creates exactly this exposure, where changing an identifier yields another customer's data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Broken object level authorization on the account resource
Why this is correct
The API authenticated the caller but never verified that the caller owned account 8842 before returning its transactions, which is the defining characteristic of broken object level authorization. Access control must be enforced per object on every request using the authenticated identity, not merely by requiring a valid session. This is why a legitimate user can read another customer's financial records simply by changing the identifier.
- ✗
Cross-site request forgery against the transactions endpoint
Why it's wrong here
CSRF abuses a victim's ambient browser credentials to make the victim's browser send an unwanted request, and it typically requires a state-changing action plus a missing anti-CSRF token. Here the attacker is the authenticated caller directly requesting another customer's data, and the problem is missing ownership checks rather than a forged browser request, so CSRF does not describe this flaw.
- ✗
Server-side request forgery through the account identifier parameter
Why it's wrong here
SSRF involves the server making outbound requests to destinations chosen by the attacker, often to reach internal metadata services or protected networks. The account identifier here selects a database record rather than a network destination, and the response is another customer's transaction data, so no outbound request behavior is involved and SSRF is not applicable.
- ✗
Insecure direct object reference in the session token generation
Why it's wrong here
Session token generation concerns randomness and entropy of the token itself, and a weak token would let an attacker guess or predict session identifiers. In this scenario the session token is valid and belongs to the requester; the exposure comes from the account identifier in the URL not being authorized against that identity, so token generation is not the weakness.
About these practice questions
One of 322 original GCIH practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.