The Canary Channel: When a Client Header Picks Your Privilege Level
The challenge
ParcelPal's Android app asks the backend what it is allowed to do the moment it launches, and it tells the server which release channel it belongs to in a header. You have the launch request in a repeater. The obvious move is to try the channels the API admits to knowing about, and that gets you nothing interesting: stable and beta return much the same configuration. The value you want is not in that list. Read what the server hands back carefully, because one field in the ordinary stable response names a channel the client never asks for, and that channel is served a build configuration meant for internal devices only. Send the request as that channel and submit the credential it exposes.
What you'll learn
- Recognise a response that varies on a client-controlled header
- Read an ordinary response for references to non-obvious variants
- Understand why an error message's list of valid values is not authoritative
- Explain why a client must not choose its own privilege level
- Tell a live credential from a test one by its prefix
Skills tested
Prerequisites
- Reading an HTTP request and response
- Basic JSON
How it works
Mobile apps ask a config endpoint what they are allowed to do, and they usually identify themselves while doing it: a version, a platform, a release channel. The moment the server changes its answer based on one of those values, that header is an access-control decision made by the client, and the client is under the attacker's control.
The instructive part of this one is where the pointer lives. Send a junk channel and the API returns known: ["stable", "beta"], which looks like an enumeration of valid values. It is not. It is the set of channels the server is willing to name. Treating an error message as authoritative is how people conclude there is nothing there and move on.
The actual reference was in the first response, before any tampering: flags_manifest points at /v1/config?channel=canary. Nobody classified that field as sensitive because it is just a path, but it names the third channel. Sending canary returns a build config with courier_debug_overlay enabled and a debug object containing dispatch_api_key.
The pp_live_ prefix is what turns this from a curiosity into an incident. That is a production credential in an internal build's configuration, served to any device that claims the right channel.
Common mistakes
- Trusting the error body's list.
known: ["stable", "beta"]is what the server admits to, not what it serves. - Skimming the stable response for something secret-looking. The pointer is a path, the least interesting-looking field on the page.
- Brute forcing channel names. Unnecessary. The name is handed to you in the first response.
- Submitting the channel name. The answer is the credential the channel exposes, not the channel.
- Changing the Host header while experimenting. The guard returns a 404 and it looks like the endpoint died.
How to defend against it
The bug is not the canary channel. It is that a header decides which configuration a caller receives.
- Derive entitlement from the authenticated session or a signed build attestation, never from a self-declared header.
- Keep internal build configuration on a separate endpoint behind real authorisation rather than a value in the same response shape.
- Do not put credentials in client-delivered config at all. Anything shipped to a device is public; proxy the dispatch call server-side instead.
- Scan responses for live credential prefixes in CI. A
pp_live_string in any client-reachable payload should fail the build. - Avoid leaking variant names in public responses, and treat a list in an error message as a design decision rather than an accident.