ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

All maker projects

IoT / Backend Security / Threat Modeling

IoT sensor security: validate messages and reject replay

Educational reference / No physical hardware testing claimed

A sensor reading is data, not authorization. A JSON body with a deviceId field does not establish who sent it, whether it has been replayed, or which tenant owns it. The backend must decide those questions independently.

The site's existing validated-sensor-message snippet checks synthetic payload shape and bounds; it does not authenticate a physical sensor or provide production-grade device identity. This guide explains what remains beyond schema validation.

By Jeffrey Monica

How the example works

  1. 01Define the telemetry envelope

    Document schema version, authenticated device principal, message ID, measurement type, units, bounds and allowed tenant. Reject unexpected or malformed values.

  2. 02Authenticate the device

    Use server-validated device credentials over an authenticated channel. Do not take the JSON body deviceId as sufficient proof of origin or authorization.

  3. 03Handle replays atomically

    Associate message IDs or monotonic sequence numbers with the authenticated device. Reserve a message identifier atomically before committing state, including concurrent duplicate arrivals.

  4. 04Authorize the resource

    Enforce allowed tenant, device and measurement combinations on the server. A valid credential must not permit writing someone else's data.

  5. 05Test real failure paths

    Simulate duplicate delivery, delayed packets, timestamp skew, reconnects, invalid data, and an HTTP response lost after a successful commit. Verify durable writes, not only status codes.

Reference code

TypeScript — conceptual sketch. Read the limitations below before using this code with real hardware or network services.

TypeScript — conceptual sketch
// Deliberately incomplete teaching sketch.
// A production server must verify credentials and use atomic storage.
type Device = { id: string; tenantId: string };
type Reading = { deviceId: string; messageId: string; value: number };

function checkIdentity(device: Device, reading: Reading) {
  if (reading.deviceId !== device.id) throw Error('wrong device');
  if (!Number.isFinite(reading.value)) throw Error('invalid value');
  // Still required: atomic per-device deduplication before commit.
  // Still required: tenant/resource authorization and audit evidence.
}

Test cases to check

  • A schema-valid reading with a mismatched device identifier fails the identity check.
  • Two simultaneous deliveries of the same message must create at most one durable write once atomic deduplication is implemented.
  • A valid-looking payload never bypasses the authenticated tenant's object authorization.

Limits & safety

  • The example is a threat-model sketch, not an implementation of cryptography, replay storage or network authentication.
  • The related working snippet tests synthetic field validation only.
  • Never test third-party connected devices without permission.

Official references

Public conversation / GitHub Discussions

Discuss this article

Public comments are being set up. There is no live comment feed yet, and this page will not load a third-party widget until the discussion repository is configured.

Send a private correction or question →