Engagement record
- Sector
- Consumer logistics and scheduled pickup, United Arab Emirates
- Scope
- Customer-facing platform, booking flow and supporting API
- Headline finding
- Customer information exposure across account boundaries
- Driver
- Pre-growth security assessment
- Outcome
- Findings remediated and verified by retest
- Confidentiality
- Client not named; findings described by class
Context
A logistics platform holds an unusually sensitive combination: names, phone numbers, home and hotel addresses, travel dates and flight details. Individually each is ordinary. Together they describe when a specific person’s home is empty and where their luggage will be.
That combination is why authorisation on this kind of platform deserves more scrutiny than its transaction volume suggests.
Approach
Two accounts before anything else
Testing began with two separate customer accounts. Every identifier the platform surfaces (bookings, addresses, contact records, tracking references) was replayed from the second account, on read and write paths alike.
The booking state machine
The flow was mapped as a state machine first: created, scheduled, collected, in transit, delivered, cancelled, refunded. Testing targeted the transitions rather than the endpoints, because that is where assumptions about who may act live.
The API as the real surface
The mobile and web clients were treated as the least interesting part. Whatever the interface hid, the API was asked directly.
Unguessable is not unauthorised. Identifiers leak through exports, notifications and referral links.Report, authorisation section
What was found
Findings are described by class and impact. Reproduction detail stays in the client’s report, a case study that hands a reader a working attack against a former client is a breach, not marketing.
| Class | What it meant |
|---|---|
| Broken object-level authorisation | Booking and customer records reachable from an unrelated account by identifier. |
| Excessive data exposure | API responses returning substantially more of the customer object than any interface displayed. |
| State transition gaps | Actions accepted in states where the business logic did not intend them. |
Outcome
The exposure was demonstrated against accounts created for the engagement rather than against real customer records: one record proves an authorisation flaw as convincingly as a million, and extracting more would have been the wrong call.
Findings were delivered with the specific corrected pattern for the platform’s framework, and every one was retested in a clean session after remediation.
Questions
How much does a penetration test cost for a logistics or delivery platform?
Penetration testing for a logistics or delivery platform is priced on the number of testable surfaces and roles, not on order volume. The customer app, any courier app, the booking API behind them and any partner integration each carry their own authorisation model. A fixed quote follows a short scoping call, with no hourly billing, and our published minimum engagement is $10,000.
How long does a penetration test take for a logistics or delivery app?
A logistics or delivery engagement runs five to fifteen working days of testing for the customer app and the booking API, plus two to three days of reporting, with roughly five days added per mobile platform. Retesting after remediation is part of the engagement, not a separate line item.
What should be in scope for a last-mile delivery platform penetration test?
On a last-mile delivery platform the booking API belongs in scope before anything else, because the web and mobile clients are only clients of it. Around it, include tracking reference lookups, saved addresses, contact records and any partner integration that can read or write a booking. That is where OWASP API Security Top 10 failures concentrate.
What customer data is exposed in a logistics or delivery platform data breach?
A breach of a logistics or delivery platform exposes names, phone numbers, home and hotel pickup addresses, travel dates and flight details. Each field alone is ordinary. Together they describe when a specific person's home is empty and where their luggage will be, which makes it a personal data exposure under UAE data protection law as much as a security problem.
Can someone open another customer's booking just by changing the tracking number?
Yes, if the tracking reference is the only thing the lookup checks. Short or sequential references can be enumerated, and random ones leak through exports, notifications and referral links, so unguessable is not the same as authorised. The flaw class is broken object-level authorisation, or IDOR, and every booking read has to check who is asking.
Why does our API return more customer data than the app shows?
APIs return more than the interface shows because the filtering lives in the client, not the server. A screen displaying a name and a delivery window is often backed by a response carrying the whole customer object. OWASP calls this excessive data exposure, and the data is already on the wire, so the API is tested directly rather than through the app.
Will penetration testing create live delivery jobs or dispatch real drivers?
Testing does not create live delivery jobs or dispatch drivers: bookings are created in accounts provisioned for the engagement rather than against real customer records. Denial-of-service techniques are excluded by default, and destructive actions against existing data are never performed without written approval.