I stumbled across a simple IDOR yesterday after ordering something online. Here's how I found it: After placing my order, I noticed the receipt URL contained two parameters: `/order/receipt?orderId=12345&codeId={uuid}` Opening this URL returned the full order details, including the shipping address and payment method. Removing the `codeId` parameter returned an "invalid code" error. Since the `codeId` was a UUID, it wasn't something I could simply increment. But I wondered what would happen if I kept my valid UUID and changed the order ID. My order: `/order/receipt?orderId=12345&codeId={my-uuid}` Another order: `/order/receipt?orderId=12346&codeId={my-uuid}` No luck. The request was rejected. Then I had another thought. What if the backend wasn't validating the UUID properly? What if it accepted the order ID itself as the `codeId`? So I tried: `/order/receipt?orderId=12345&codeId=12345` It worked. My full order details were returned, even though I hadn't supplied the UUID. Now for the interesting part. I incremented both parameters: `/order/receipt?orderId=12346&codeId=12346` And there it was. Another customer's order details, shipping address, and payment method information. Because order IDs were sequential, this exposed thousands of customer records. #BugBounty Tip: Don't assume an endpoint is secure just because it uses UUIDs. When multiple parameters are involved, test how they're validated together, not just individually. A UUID is not an authorization check.