Exercise 1: Why Both the Order ID and the Email Are Checked — Possible Solution ==================================================================== WHAT CHECKING ONLY THE ORDER ID WOULD ALLOW ------------------------------ Per this capstone's own Chapter 7 material, order IDs are typically sequential or otherwise guessable/enumerable. If the lookup function only confirmed that an order with the given ID existed, any guest could view any other customer's order simply by trying different ID numbers in the URL - exactly the broken-access-control exploit Chapter 7 described for an unchecked /order-status/?order_id=N page. WHY THE EMAIL CHECK CLOSES THAT GAP ------------------------------ Per this capstone, the function requires that "the order's billing email must match the email the requester actually supplied, not just any valid ID." An attacker guessing order IDs would also need to correctly guess the exact billing email tied to that specific order - information they don't have simply from knowing the order exists, which makes blind enumeration no longer sufficient on its own. WHY THIS IS THE SAME PRINCIPLE AS CHAPTER 7'S OWN OWNERSHIP CHECK ------------------------------ Per this capstone, this mirrors Chapter 7's own logged-in ownership check (comparing the order's customer ID against the currently logged-in user's ID) - applied here to a guest context with no login at all, where the billing email serves as the proof of ownership instead of a session's own user ID. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains what the order-ID-only version would allow (ID enumeration), and correctly explains why requiring the matching email closes that gap, tying the mechanism back to Chapter 7's own ownership-check principle applied to a guest, non-logged-in scenario.