Testing IoT Cloud APIs from the Device Side
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.
What to Test from the Device Side
Once you can see the device’s traffic, a handful of test areas cover the trust between device and cloud, each probing a different assumption the backend makes:
| Test | What you probe | Flaw it reveals |
|---|---|---|
| Certificate validation | Will the device talk through your proxy at all? | MITM exposure if it accepts your cert |
| Authentication & tokens | Token origin, expiry, replay, swapping | Non-expiring or reusable device credentials |
| Authorization (BOLA) | Change a device or resource ID to one you don't own | Broken object-level authorization, fleet-wide control |
| Command channel | How the device decides a command is legitimate | Remote control via unauthenticated commands |
| Input handling (both ends) | Malformed telemetry up, crafted responses down | Injection and parser memory corruption |
| Information leakage | Verbose errors, over-sharing responses and telemetry | Recon data and privacy exposure |
| Update channel | Signature check, downgrade, attacker-served image | Remote code execution into every device |
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.
# 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: the token or credential it presents, where it 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, whether the API accepts a malformed or missing token, leaks information in error responses, or lets one device’s token act as another, because 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.
# 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/state200 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 and Input Handling
The cloud-to-device direction deserves its own scrutiny: how the backend sends commands and how the device decides a command is legitimate. 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, and testing both halves together, the device’s trust and the API’s authorization, is what exposes it.
Input handling runs both ways. The data the device sends and the data it receives are both parsed by something, and parsers are where injection and memory-corruption bugs live. Send the backend malformed telemetry and oversized fields to probe its validation, and observe how the device handles unexpected responses, because embedded devices often have fragile response parsers built on the assumption that the cloud only ever sends well-formed data.
Look for Information Leakage
APIs leak in their responses and errors: verbose messages that reveal internals, responses that include more data than the device needs, or endpoints that expose other users’ information, so catalog what the API returns and ask whether each field is necessary, because over-sharing is both a privacy issue and a reconnaissance gift. 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 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, and the value of testing from the device side is seeing that 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 a concrete change that together close the API surface 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.
