Mobile Networking · Watching Traffic · Lesson 5 of 5

Challenge: Checking FitTrack

Test your team's fitness app on your own phone and find its leaks.

The Case Brief

You've just joined a small team that makes a running app called FitTrack. Before the next release, your lead asks you to check what the app sends over the network.

You set up an intercepting proxy on your laptop. You use a spare Android test phone the team owns, route it through the proxy, and install the proxy's certificate on it. The phone saves it in the user certificate store.

First you try the version of FitTrack from the app store. The log fills with failed connections, and you can't read any of its requests. Your browser on the same phone works fine through the proxy.

Then you install the team's debug build of FitTrack, which a developer set up to trust user certificates. Its requests appear in the log as readable text.

Both versions are built for current Android. Before you go further, you want to understand why only one of them works.

Reading the Log

With the debug build, you sign in as a test user and save a run. The proxy shows these requests:

• GET http://img.fittrack.example/badge.png
• GET https://api.fittrack.example/v1/runs?email=jo@example.com
• POST https://api.fittrack.example/v1/runs with the run's route in the body

Your lead asks you to flag one thing first: the request that puts personal details somewhere they could end up saved in server logs and other records nobody intended. You look closely at where each request carries its data.

Before You Share

You open the second request to write a bug report. Its headers look like this:

• User-Agent: FitTrack/4.2 (Android 15)
• Accept: application/json
• Authorization: Bearer eyJhbGciOi...
• Content-Type: application/json

Anyone who copied one of these values could act as your test user until it expires, without knowing the password. You want to redact it before you attach the capture to the bug report.

Out in the Wild

Your lead asks one more question. A real user opens FitTrack on café Wi-Fi, and the app sends that same request:

GET https://api.fittrack.example/v1/runs?email=jo@example.com

The café isn't running a proxy, and the user's phone trusts no extra certificates. Your lead wants to know what the café Wi-Fi owner could learn from this one request, compared with the badge image that goes over http://.