Security researcher Rey Bango discovered the exposure while investigating a fraudulent order placed against his own account. The order confirmation pages for Express — the US fashion retailer — were publicly accessible with no authentication required. The only variable in the URL was the order number. The order numbers were sequential. Anyone who knew one valid order ID and incremented the number had access to every other customer's confirmation page.

What those pages exposed was not trivial. Customer names, contact details, shipping addresses, order contents, and partial card data — enough to profile a customer, validate a stolen identity, or construct a convincing phishing message — were visible to anyone who ran the sequence. No credentials. No exploitation. Just arithmetic.

TechCrunch confirmed the exposure independently before notifying Express. The pages were patched after notification.

Why This Pattern Keeps Appearing

Insecure direct object reference — IDOR — is not a sophisticated vulnerability class. It does not require reverse engineering, privilege escalation, or chained exploits. It requires finding a reference to an object and asking whether the application checks who is asking for it. In this case, the answer was no.

Sequential identifiers compound the problem. A randomised or non-guessable order ID at least forces an attacker to obtain a valid reference before pivoting to others. Sequential integers are an open invitation to enumerate. The combination — publicly accessible confirmation pages, no authentication, sequential order IDs — means the exposure was not a single misconfiguration but three compounding decisions, each of which made the next one worse.

The fraud angle is worth noting. Bango found this while investigating a fraudulent order on his own account. The attacker who placed that fraudulent order almost certainly already knew how the confirmation pages worked. The question is not whether this was discovered by a malicious actor before Bango found it. It is whether it was discovered repeatedly, quietly, and without anyone noticing.

Defender Actions

  • Audit every endpoint that returns customer or order data and verify that server-side authorisation checks confirm the requesting user owns the resource — client-side checks and obscurity are not controls
  • Replace sequential identifiers on any externally accessible resource with UUIDs or cryptographically random tokens — enumeration should require more than incrementing an integer
  • Treat order confirmation pages, invoice links, and delivery tracking URLs as authenticated resources by default — the assumption that these are low-sensitivity because they require a prior purchase does not hold when the identifier is guessable
  • In SIEM, alert on sequential or high-volume access patterns against order or account endpoints from single source IPs — automated enumeration has a detectable signature if you are looking for it
  • Include IDOR testing as a standard item in application security assessments — it consistently appears in breach disclosures precisely because it is easy to overlook and easy to find

The patch is in. The data that was exposed before the patch is not retrievable.

None