Waze Vulnerability

A month or so ago, I ended up on on the Waze website – specifically, their “live map".

As I often do, I found myself poking around Firefox’s developer tools, looking to see which API endpoints the webapp was interacting with.

I noticed that this particular webapp called an which looked like this:


The bottom, left, right and top URL parameters are fairly self explanatory (they define the bounding box over which the API is queried). types defined the data that should be included in the API call response, and ma, mj, and mu seemed to specify the maximum number of alerts, jams, and users to be returned.

As it often does, curiosity got the better of me. I tried defining a bounding box that covered the whole planet (by setting bottom=-90, top=90, left=-180 and right=180), and just like that, the API was returning 100+mb of JSON data. This JSON data included planet-wide user-contributed alerts (excluding the US, which uses a different API endpoint but suffered the same problem). These alerts are user-contributed notices of traffic jams, police, broken down cars, pot holes and the like.

Alerts across the planet

It turned out that the ma parameter was being ignored – users and jams were capped at the specified value (which was limited server-side at ~300), but there was no upper bound on the number of alerts being returned.

This issue probably doesn’t pose an issue to users, but wasn’t the intended behaviour of the API endpoint – competitors and other interested parties could trivially harvest all user-contributed Waze data in a single API call.

Waze is owned by Google, so I reported the problem to them via their preferred channels. After an initial misunderstanding about the nature of the issue, they agreed that it was an abuse risk and decided to award a $500 bounty!

The timeline was:

This wasn’t a very clever bug, nor was it a very severe one. However, it goes to show that minor issues which are fairly inconsequential to end users can still be (somewhat) valuable to Google.