Unauthenticated Real-Time GPS Tracking of Every Chauffeur

The Vulnerability

The mobile app's backend exposed a "drivers nearby" endpoint that the app calls during the booking flow to show available cars around the customer. The endpoint accepted a latitude, longitude, and radius and returned every active driver in that area:

GET /api/drivers/nearby?latitude=<lat>&longitude=<lng>&radius=5000

The problem was that this endpoint enforced no authentication whatsoever. No API key, no session token, no cookie, and no CAPTCHA were required. A bare request from any machine with no account returned a full HTTP 200 response with live data. Sending the same request with a deliberately fake bearer token returned identical data, confirming the token was never validated:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer bogusxyz123notreal" \
  "https://REDACTED/api/drivers/nearby?latitude=<lat>&longitude=<lng>&radius=5000"
# -> 200

The response body was never truncated and the running total was uncapped. Every counted driver's full coordinate was returned, not just a count. Coordinates were precise to 6 to 10 decimal places, which is well under a meter of accuracy.

{"totals":<N>,"data":[
  {"id":"...","latitude":<lat>,"longitude":<lng>,"distance":10,"eta":4},
  ...
]}

The Attack

Two distinct attacks were possible against this single endpoint, both fully unauthenticated.

Bulk Fleet Mapping

By querying different city coordinates, an attacker could enumerate the entire active fleet market by market. In one unauthenticated snapshot across several markets, many hundreds of active drivers were exposed at once. Plotting a single response on a map reproduced the complete live position of an entire city's fleet from one anonymous request. This required nothing more than curl and a list of public city coordinates, so the barrier to entry was effectively zero.

Continuous Individual Tracking

The more serious attack was tracking a single, identifiable driver over time. In several markets, drivers carried stable per-vehicle identifiers that reappeared across requests with updated coordinates. By polling the same coordinate on a short timer and matching identifiers between snapshots, an attacker could reconstruct one driver's continuous movement.

The proof-of-concept saved two polls 25 seconds apart and compared them:

curl -s "https://REDACTED/api/drivers/nearby?latitude=<lat>&longitude=<lng>&radius=5000" > p1.json
sleep 25
curl -s "https://REDACTED/api/drivers/nearby?latitude=<lat>&longitude=<lng>&radius=5000" > p2.json
# match ids between p1 and p2, report which coordinates changed

Across the 25-second gap, nearly all identifiers persisted and several had moved tens to hundreds of meters. Repeating this on a tighter interval reconstructed a full route. It is worth noting that the endpoint did not return a cross-origin header, so a malicious website could not read the data from a victim's browser. The attack was server-side, run from a script, which is exactly how the proof-of-concept was built.

The Impact

This was bulk exposure of the live geolocation of identifiable workers, plus a working primitive for shadowing any one of them in real time.

Running the poll loop for several minutes against one city coordinate reconstructed the complete route of a single driver: a sequence of live GPS fixes spanning roughly two kilometers of travel at normal road speed along a coherent path through several connected districts, with the same identifier persisting across the majority of consecutive unauthenticated polls. This was demonstrated, not theorised.

• Worker safety: a stalker or hostile actor could locate and follow a specific driver throughout a shift, with zero barrier to entry.
• Passenger privacy: if a tracked driver was carrying a fare, the passenger's origin and destination were indirectly recoverable from the trajectory.
• Competitor intelligence: unauthenticated fleet density and coverage data was retrievable across every active market.
• Regulatory exposure: real-time location of a worker is personal data under EU and UK data protection law. Publishing it to the open internet is unauthorized processing and a reportable data exposure.

Scope was kept honest. The endpoint did not expose driver names, photos, license plates, or phone numbers, and the per-record thumbnail was a generic vehicle icon. A sibling endpoint that took a single driver identifier returned 404 when called unauthenticated, so an identifier could not be mapped to a named person through the public API. The leak was the location of identifiable-but-unnamed workers, not direct name-to-GPS deanonymization. A sweep of around 40 candidate sibling routes confirmed this nearby-drivers route was the only sensitive unauthenticated endpoint. Every customer, booking, reservation, and profile route correctly enforced authentication and returned 401 or 403.

Remediation

• Require a valid authenticated session on the nearby-drivers endpoint, the same way the rest of the API already does.
• Reject requests with missing or invalid tokens instead of returning live data regardless of the token.
• Reduce coordinate precision returned to clients (coarse pins are enough for a booking flow) and cap the number of records returned per request.
• Rotate per-vehicle identifiers frequently so a single driver cannot be correlated across polls into a continuous trajectory.
• Add rate limiting and anomaly detection on the endpoint to flag the rapid, repeated polling that individual tracking requires.