Fledge REST API hardening starts before sensor onboarding

Fledge is an open-source platform for collecting and processing industrial data at the edge. Its REST API can configure services, manage plugins, and change the path of sensor data. The API is therefore part of the control plane, even when the device is deployed in a maintenance network.

Fledge documentation says authentication has become the default in version 3.0 and later, with username and password or certificate authentication. It also says the REST API can be switched to require HTTPS. Older versions and some test configurations may have security features disabled by default. A deployment inventory needs to distinguish the installed version and the effective configuration from the documentation's current default.

Counts provide a starting point

A count-only ZoomEye probe on 2026-11-16 used sub_type=all, page 1, and pagesize 1. The results were:

Query role Exact query Count
Application app="Fledge" 0
Title title="Fledge" 336
Body http.body="Fledge" 13,598

The large body count is not a reliable deployment count because the term can appear in unrelated industrial, advertising, and software content. Title matches are more relevant but still need page verification. The application fingerprint returned no rows in this observation.

Verify the effective mode

Check the API protocol, the authentication mode, the user roles, and the certificate store on the running instance. Do not infer them from a package version. Test an unauthenticated request and confirm that it is rejected. Then test a valid low-privilege account against an administrative endpoint and confirm that the role check is enforced.

Disable unencrypted HTTP when password authentication is in use. If a certificate is used, validate its chain and renewal path. Protect the certificate store and its private keys, and avoid embedding a reusable administrator password in plugin configuration. Give collectors and plugin services only the roles they need.

Review the network path to the API. A local-only service can still be reached through a misconfigured container port, a diagnostic tunnel, or a reverse proxy. Bind the API to the intended interface and use a firewall or network policy as a second boundary. Keep the management API separate from the sensor field network where possible.

Treat configuration as control

Before onboarding a sensor, record its source, plugin, destination, and owner. Review whether the API can change those mappings. A user who can alter a south service can redirect or suppress data. A user who can change a north service can send industrial data to an unexpected destination.

Set limits on uploads, plugin installation, and request size. Log login failures, role changes, plugin changes, and service restarts. Retain enough context to reconstruct a configuration change without logging credentials or full sensor payloads.

Monitor the API for protocol or authentication drift after upgrades. A configuration that was secure in one release may expose a new endpoint or change a default. Fledge deployments need a version-aware review of the management plane before the first sensor and after every upgrade.

References