Security Notice

Elements Hub does not currently provide any built-in authentication, authorisation or transport security. Anyone who can reach the listening socket can call every endpoint described in this manual, including connecting and disconnecting devices, triggering calibrations, and reading live image streams. Deploy the hub only on trusted networks, behind appropriate network controls.

This page summarises the security-relevant defaults of the hub, the threat model they imply, and the practical mitigations available to integrators.

Current Security Posture

The hub is designed to live next to the instrument on a controlled workstation or in a controlled production network — not as an internet-facing service.

Network Binding

The hub listens on http://localhost:42042 by default. The chosen port can be observed in the startup log and is also exposed via the Swagger UI Guide at http://<host>:<port>/swagger/.

To bind a different address — for example to expose the hub to other machines on the LAN — pass --urls:

# Loopback only (default behaviour, explicit form)
ElementsHub.exe --urls "http://localhost:42042"

# All interfaces — exposes the hub to every reachable network
ElementsHub.exe --urls "http://0.0.0.0:42042"

# A specific NIC IP
ElementsHub.exe --urls "http://192.168.10.5:42042"

Binding to 0.0.0.0 or to a non-loopback address makes every endpoint reachable from any host that can route to the chosen IP. Combined with the lack of authentication, this is equivalent to placing administrative control of the instrument on an open network share. Do this only in segregated networks where every participating host is trusted.

If the default port is already in use, the hub falls back to a free port on the same loopback address and prints the actual binding in the startup log. Clients that hard-code 42042 must be prepared to receive an alternative port.

Cleartext Traffic

The hub does not configure HTTPS by default. Measurement results, image streams and configuration data are transmitted in cleartext. On a single workstation this is generally acceptable; over a shared network it is not.

If you must expose the hub across a network, place an HTTPS-terminating reverse proxy (IIS, nginx, Caddy, Envoy) in front of it and disable the hub's direct binding on the external interface. The proxy can also add the authentication that the hub itself lacks.

Threat Model

Assume any process or user that can connect to the hub's listening socket can:

• Connect any discovered device and read live image streams from it.
• Trigger calibrations, including ones that overwrite previously stored reference values.
• Read or download measurement containers — including ones still in progress.
• Read the hub's log file via GET /v1/logs, which may contain device serial numbers and operational metadata.
• Initiate an in-place application update via POST /v1/app-updates/action.

Do not treat the listening socket as confidential by virtue of running on a workstation. On a multi-user host, every local user account can reach localhost:42042.

Recommended Mitigations

For each deployment scenario, pick the smallest set that brings residual risk into your operational comfort zone:

Future Work

Authenticated, authorised and TLS-protected access is on the roadmap. Until shipped, treat this page as the authoritative description of the hub's security posture — do not assume any implicit protection.