How DoorDash's API Let Us Count Every Order Ever Placed

DoorDash processes millions of food delivery orders every day. Each order gets a unique identifier. If you can enumerate those identifiers, you can determine exactly how many orders the platform has processed. That is competitive intelligence that DoorDash would very much prefer to keep private.

While testing DoorDash's API through their bug bounty program, we found that a specific operation returned different error messages depending on whether a record existed or not. A valid order ID produced one response. An invalid order ID produced a distinctly different response. There was no rate limiting on this operation, so we could query it as fast as our connection allowed.

This is a classic differential response vulnerability. The API was leaking information through its error handling. By observing which IDs returned "exists" responses versus "not found" responses, an attacker could map the entire range of valid order identifiers. Combined with the lack of rate limiting, this turned a subtle information leak into a full enumeration attack.

The impact is business intelligence exposure. Knowing the total number of orders, the rate of new orders, and the ID format gives competitors, investors, and journalists data that DoorDash controls carefully in their public filings. It also reveals the internal structure of their data model, which helps with further testing.

We reported this through DoorDash's HackerOne program. The fix is straightforward: return identical error responses regardless of whether a record exists, and add rate limiting to prevent bulk queries.

Differential responses are everywhere. Most developers do not think about the information their error messages communicate. Every time your API says "user not found" instead of "invalid request," you are giving an attacker a binary oracle. Pay attention to what your errors reveal.