A transit multi-step checkout accepts the price totals submitted from the browser on step 3. What should the tester emphasize?
Select an answer to reveal the explanation.
Short Explanation
Letting the browser tell the cashier how much to charge is like letting the customer write the receipt. Multi-step checkouts that trust client price fields are classic business-logic trust failures. Hide the field, switch to POST, or bolt on a WAF — none of that replaces server-side recomputation.
Full Explanation
Transit multi-step checkouts that accept price totals submitted from the browser on a later step violate a core web trust boundary: prices, discounts, and entitlements must be recomputed server-side from authoritative catalog and policy data. Client-supplied totals are attacker-controlled inputs even when the UI looks locked.
Treating client totals as authoritative because the field is visually disabled confuses presentation with security. Believing only GET parameters can be tampered while POST bodies are trusted is false—both are client-controlled. Claiming a WAF signature set removes the need for business-logic testing ignores logic flaws that signatures rarely catch.
Exam caveat: hidden fields, JSON bodies, and multi-step tokens are still client-side; integrity of amounts belongs on the server.
Operational check: complete the civic checkout to the price-confirmation step, modify the submitted total or line items within authorization, and verify whether the server recomputes from trusted state. Report acceptance of client prices as a business-logic finding with fare or fee impact noted for the transit agency. 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.