securitytechnician.wiki
Security About 2 min read

API and event security

Check who can publish an event and what the consumer may do with it. Validate the message, its source and its authority before acting.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.

Verification and testing

On this page

Overview#

Physical security integrations commonly mix commands, snapshots, configuration, telemetry, alarms, audit events, and identity data on one platform. Treat each as a separate capability with independent authorisation, sensitivity, integrity, ordering, retention, and side effect rules.

Command contract#

A state changing API should define:

  • authenticated subject and workload identity;
  • explicit action and resource scope;
  • preconditions and current state/version;
  • request identifier and idempotency behaviour;
  • authorisation decision and policy version;
  • bounded timeout, retry rules, and uncertain outcome handling;
  • physical side effect and safe failure state;
  • immutable audit correlation from request through device outcome;
  • denial and partial failure semantics.

Never retry a high impact command blindly after timeout: the first request may have succeeded even if its response was lost. Query authoritative state or use a protocol supported idempotency key before deciding.

Event contract#

An event envelope should carry stable type/version, source identity, event identity, occurrence time, observation/ingestion time, sequence where meaningful, site/tenant scope, subject/object identifiers, data classification, integrity context, and correlation/causation identifiers.

Consumers must define behaviour for duplicate, delayed, missing, reordered, malformed, unauthorised, unknown version, and replayed events. Delivery acknowledgement means the broker or receiver accepted a message; it doesn't prove the physical event occurred or that an operator acted on it.

Broker and topic security#

  • Authenticate clients uniquely and authorise publish and subscribe separately.
  • Keep tenant/site/device identifiers server derived when possible.
  • Prevent wildcard subscriptions from escaping the caller's authorised hierarchy.
  • Review retained messages, durable sessions, shared subscriptions, dead letter queues, and replay stores as data repositories.
  • Bound payload size, inflight messages, session lifetime, queue depth, retry rate, and reconnect behaviour.
  • Encrypt the connection, validate peer identity, and avoid plaintext fallback.

Webhooks and callbacks#

Authenticate the sender with mTLS or a well designed signature/token mechanism; validate timestamp/freshness and replay identifier; acknowledge only after durable acceptance; separate delivery retries from business processing; and don't follow arbitrary callback redirects. Apply outbound allowlists to prevent server side request forgery.

Data minimisation#

Avoid placing full card numbers, biometric data, faces, tokens, passwords, internal URLs, or unnecessary location context in events and logs. Use opaque stable identifiers with separately controlled lookup when the integration doesn't require raw sensitive data.

Sources#

View MarkdownSuggest an editBack to top ↑