# Security Notice

> [!note] Tato stránka ještě není přeložena do češtiny a zobrazuje se anglicky.


> [!warning]
> 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

| Layer | Default | Implication |
| --- | --- | --- |
| Authentication | None | Any caller is treated as fully privileged. |
| Authorisation | None | All endpoints are equally reachable. |
| Transport | HTTP (cleartext) | Traffic is observable on the local network. HTTPS is not configured out of the box. |
| Network binding | `http://localhost:42042` by default | Only loopback connections are accepted unless explicitly changed. |
| CORS | `AllowedHosts: "*"` | Cross-origin requests are not restricted by the hub. The browser still enforces the same-origin policy unless CORS is configured. |
| Rate limiting | None | A misbehaving client can pin a device or saturate the host. |

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](rhopoint-elements-hub-swagger-ui-guide.md) at `http://<host>:<port>/swagger/`.

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

```bash
# 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"
```

> [!warning]
> 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:

| Scenario | Mitigation |
| --- | --- |
| Single-user lab workstation, single integrator | Keep the default loopback binding. Do not change `--urls`. |
| Multi-user workstation | Restrict access to the hub's listening port via Windows Firewall to the integrator's account. |
| LAN-attached production cell | Run the hub behind a reverse proxy that terminates TLS and enforces authentication (mTLS, OAuth or API key headers). Bind the hub itself to loopback so it is only reachable through the proxy. |
| Multiple instruments per workstation | One hub instance per device, bound to distinct loopback ports. |
| Remote support / diagnostics | Use an out-of-band channel (RDP, SSH tunnel) rather than exposing the hub directly. |

## 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.