Testing IoT Cloud APIs From the Device Side

Testing an IoT device's cloud API from the device side by intercepting and replaying its traffic

A connected device is only half the product. The cloud API it talks to is the other half, and it is attack surface that scales: a flaw there can affect every device at once. Testing it from the device’s perspective, by intercepting and manipulating the traffic the device actually sends, reveals the trust assumptions that a purely external API test would miss. Here is how.

The Cloud Is Part of the Device

It is easy to scope an assessment to the box on the bench and forget that most of its behavior depends on a cloud backend. The device authenticates to the cloud, sends telemetry, and receives commands and updates, and every one of those interactions is attack surface. A weakness in the API can compromise the device, the user’s account, or the entire fleet.

Testing from the device side matters because the device is a trusted client in the system’s design, and trusted clients are where assumptions hide. The backend may assume the device only sends well-formed, honest data, only requests its own resources, and only acts within its role. Speaking to the API as the device, but not playing by its rules, is how you test whether those assumptions hold.

Intercept the Device’s Traffic

The first step is to see what the device actually sends. Position an intercepting proxy between the device and the internet, point the device’s traffic through it, and capture the API calls. Because the device usually uses TLS, you will need to handle certificate validation, which is itself a test, covered below.

# route device traffic through an intercepting proxy and watch the API calls
mitmproxy --mode transparent --showhost
# observe: endpoints, auth tokens, request/response shapes, device identifiers

Watching the real traffic reveals the API surface as the device uses it: the endpoints, the authentication scheme, the device and user identifiers, and the shape of every request and response. This is the map you test against, and it often includes endpoints and parameters that no public API documentation mentions.

Test Certificate Validation First

Whether you can intercept at all is the first finding. A device that properly validates the server certificate will refuse to talk through your proxy, which is the correct behavior. A device that accepts your proxy’s certificate, or that you can intercept by installing a CA, has weak or absent validation, a serious flaw on its own.

A device that does not validate certificates is open to a man-in-the-middle on any network it joins, which exposes its credentials and its traffic. So the act of setting up interception doubles as a test: if it is easy, that ease is a vulnerability. If it is hard, you have confirmed one defense and you move to extracting the trust anchor or testing from a rooted companion app instead.

Test Authentication and Token Handling

Once you can see the traffic, examine how the device authenticates. Look at the token or credential it presents, where that came from, whether it expires, and what happens if you replay it, alter it, or present someone else’s. A device credential that never expires, or that can be lifted and reused from anywhere, is a common weakness.

Test the failure modes too: does the API accept a request with a malformed or missing token, does it leak information in error responses, can a token from one device be used as another. These probe whether the backend actually enforces the authentication it appears to require, which is frequently weaker than the happy path suggests.

Test Authorization and Tenant Isolation

The highest-impact API flaws are usually authorization failures: a device or user accessing resources that belong to another. Take a legitimate request, change the device ID or the resource ID to one you do not own, and see if the backend serves it. If it does, you have a way to read or control other users’ devices.

# does the API check ownership, or just authentication? change the id and see.
curl -H "Authorization: Bearer <my-device-token>" \
     https://api.vendor.com/v1/devices/OTHER_DEVICE_ID/state

Example output

200 OK   {"device":"OTHER_DEVICE_ID","state":"unlocked", ...}
# BAD: my token returned another device's state -> broken object-level authorization

A backend that returns another device’s data to your authenticated request has broken object-level authorization, one of the most common and most serious API flaws. At fleet scale it can mean any user controlling any device, which is about as bad as a connected product gets, and it is invisible from the device’s normal operation.

Test the Command Channel

The cloud-to-device direction deserves its own scrutiny. How does the backend send commands to the device, and how does the device decide a command is legitimate. If the device trusts any command that arrives on its channel without verifying the source, an attacker who can inject into that channel, or who finds an API path to send commands, controls the device.

This is where the device-side and cloud-side trust meet. A device that accepts commands purely because they came from the cloud connection, combined with an API that lets an attacker send commands to arbitrary devices, is a full remote-control vulnerability. Testing both halves together, the device’s trust and the API’s authorization, is what exposes it.

Test Input Handling on Both Ends

The data the device sends and the data it receives are both inputs that something parses, and parsers are where injection and memory-corruption bugs live. Send the backend malformed telemetry and oversized fields to probe its validation; observe how the device handles unexpected or malicious responses from the cloud.

Embedded devices often have fragile response parsers, because developers assume the cloud will only ever send well-formed data. An attacker who can man-in-the-middle, or who controls a malicious server the device can be pointed at, can test whether a crafted response crashes or compromises the device. Both directions of the conversation are attack surface.

Look for Information Leakage

APIs leak in their responses and errors: verbose error messages that reveal internals, responses that include more data than the device needs, or endpoints that expose other users’ information. Catalog what the API returns and ask whether each field is necessary, because over-sharing is both a privacy issue and a reconnaissance gift to an attacker.

Device-to-cloud leakage matters too. A device that sends more telemetry than the feature requires, location, identifiers, usage patterns, expands the privacy surface and may violate the user’s expectations. Reviewing what actually crosses the wire, in both directions, frequently surfaces data flows the product team did not realize were happening.

Test the Update Channel

If firmware updates come through the cloud, that channel is a high-value target. Confirm the device verifies update signatures before installing, that it cannot be downgraded to a vulnerable version, and that an attacker who can intercept or influence the channel cannot push their own image. A weak update channel is a remote-code-execution path into every device.

Test it from the device side by observing how it fetches and validates updates, and by attempting to serve a modified or unsigned image through your interception point. A device that installs what you serve has no real update security; one that rejects it has confirmed a critical defense. This is among the most important API-related tests there is.

Tie It Back to the Whole System

The device-side API test is one piece of a full product assessment, and its findings connect to the others. A weak device credential plus broken API authorization plus a trusting command channel compound into fleet-wide control. The value of testing from the device side is seeing those connections, the chain from one trusted client to the whole backend.

Reported well, these findings give the team a clear picture of where the device-cloud trust is misplaced and how to fix it: validate certificates, scope and expire tokens, enforce per-object authorization, authenticate commands at the device, and sign updates. Each is a concrete change, and together they close the API surface that an external test alone would never fully reveal.

Where This Fits

Testing the cloud API from the device’s perspective, where the real trust assumptions live, is part of a full product security assessment for any connected product. If you want your device-to-cloud interface tested for the authorization and trust flaws that scale across your fleet, that is the kind of work we do at Berkner Tech.