Skip to main content
ZombieMutex

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

All maker projects

IoT / Backend Security / Threat Modeling

IoT sensor security: validate messages and reject replay

Original design study · no physical hardware validation

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

Read and reply using GitHub Discussions. A GitHub account is needed to post. Comments are public and subject to GitHub moderation.

For privacy, the external giscus widget does not load until you choose to open it. Opening it connects your browser to giscus and GitHub. Do not post credentials or private project data.

Open this discussion on GitHub