From Burger Order to Data Breach: An API Security Case Study

The Target Company is a large food & beverage commerce enablement platform. The platform is a powerhouse for 10,000+ restaurants, including leading Burgers, Tacos, Pizza fast food chains. A critical misconfiguration was identified within the order management API architecture. This flaw exposed sensitive customer, delivery partner, and restaurant data without requiring authentication.

The vulnerability allowed unauthorized access to hundreds of thousands of order records, including personal identifiable information (PII) such as names, phone numbers, residential addresses, email IDs, billing details, delivery partner information, and IP addresses.

This issue was responsibly disclosed to the platform’s technology executive leadership, validated internally, and subsequently remediated in a short timeframe.

---

Step-by-Step Breakdown of the Issue

Users Involved

• User A: A legitimate customer placing an online food order

• User B: Any unauthenticated external user on the internet

---

Initial Observation

While placing an order through a restaurant’s official website, the application was observed loading a large client-side JavaScript file (main.js) responsible for checkout and order processing logic.

This JavaScript file contained multiple backend API endpoints, some of which appeared to handle order lookups and transaction details.

Given the file size (several thousand lines), used gerben_javado’s Link Finder tool to extract API paths and parameters efficiently.

---

Discovery of Unauthenticated Endpoints

An unauthenticated API endpoint was identified that returned order details when supplied with a valid order hash.

Although the hash initially appeared non-predictable, something Q2BNr6hxtKK , further testing revealed the presence of a secondary API endpoint that:

• Accepted simple numeric order identifiers

• Returned the corresponding order hash

• Allowed reuse of that hash in the unauthenticated order detail API

This created a complete enumeration chain:

1. Guess numeric order ID

2. Fetch associated order hash

3. Use the order hash to retrieve full PII and transaction details

4. Repeat the process at scale

No authentication, session validation, or rate limiting was enforced at any stage of this flow.

So that flow looked like

• api[.]example[.]com/api/order/4985909 → Returns order metadata, including the hash value

• api[.]example[.]com/api/redacted/order/hash/redacted/A2BNr6hxtKK → Returns full order details and associated PII

  

---

Data Exposed

The affected API responses contained the following sensitive information:

• Customer's full name

• Mobile phone number

• Email address

• Residential delivery address

• Full billing and order data

• Delivery partner name & phone number

• Restaurant identifiers

• Order timestamps

• IP address

Both customer and restaurant operational data were exposed through this vulnerability of several hundred thousand customers and thousands of restaurants.

---

Technical Root Cause

The root cause originated from broken object-level authorization (BOLA) combined with:

• Unauthenticated access to order lookup APIs

• Predictable numeric order identifiers

• Public order-hash retrieval endpoints

• Lack of rate limiting and abuse detection

The system relied on the secrecy of order hashes instead of enforcing mandatory authentication and authorization controls, allowing any external actor to retrieve sensitive order records at scale.

---

Timeline

• Vulnerability Discovered: [Redacted]

• Reported to Organization: [Redacted]

• Acknowledged & Validation Completed: Within 24–48 hours

• Patch & Remediation Implemented: Shortly after acknowledgment

• Public Disclosure: Several months post-fix