A library voucher system is meant to redeem each code once, but simultaneous requests appear to redeem the same voucher twice. What finding class does this illustrate?
Select an answer to reveal the explanation.
Short Explanation
Two people racing through the same turnstile at once can both get in if the gate only checks after the fact. Concurrent redeems of a single-use voucher are classic race/business-logic issues — no SQLi required. DNS or cert quirks are a different conversation.
Full Explanation
A library voucher meant for single redemption that can be redeemed twice under concurrent requests illustrates a race or business-logic flaw: process controls fail under parallelism without needing classic injection. Civic benefits programs are especially sensitive because duplicate redemptions waste public funds and undermine fairness.
DNS zone-transfer failure is an unrelated reconnaissance theme and does not explain double redemption. CSRF tokens address cross-site request forgery, not automatic elimination of concurrency bugs in checkout or voucher flows. An SSL hostname mismatch is a transport-identity issue and does not cause duplicate business processing.
Exam caveat: not every TOCTOU race needs exotic tooling—simple parallel requests against state-changing civic endpoints can demonstrate the class when RoE allows.
Operational check: redeem the same voucher with near-simultaneous authorized requests, compare server-side redemption records and HTTP outcomes, and capture evidence of dual acceptance. Recommend atomic server-side redemption (transactional uniqueness constraints) rather than UI-only disablement of the redeem button. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.