Node-RED combines a visual editor with runtime nodes that can call APIs, process messages, and connect to local systems. The editor, admin API, and HTTP flow endpoints may share a host while having different exposure and authentication requirements. A generic page title does not show which of those surfaces is reachable.
At 2026-10-28 19:43 UTC, ZoomEye's web scope reported 359 matches for title="Node-RED". The SDK query requested one result with pagesize=1, so the count is the reported total for the selected title. It does not identify which matches expose the editor, a dashboard, or a custom flow endpoint.
Map each HTTP surface
Node-RED's security documentation distinguishes editor and Admin API security from the HTTP In nodes. The editor is used for flow authoring and administration. HTTP flow endpoints are application interfaces built by the flows themselves. Authentication for one route does not automatically authorize the other.
Review editor access first. It can change runtime behavior and reach credentials used by configured nodes. Then inventory every HTTP In node, its method, path, input validation, and authentication middleware. A public flow endpoint may be intentional, but it should have a clear owner and a limited function. Test whether a request can alter flow storage, trigger an administrative endpoint, or supply data that reaches a privileged node.
Apply authentication where identity matters
Use an identity-aware proxy or the supported authentication configuration for editor and admin access. Confirm that the proxy route and Node-RED bind address cannot be bypassed. If HTTP flow endpoints require accounts, implement authentication in the flow or a trusted middleware layer and return consistent denial responses. Do not rely on CORS as authorization.
Constrain node capabilities. Keep credentials in protected configuration rather than passing them through flows or debug output. Restrict filesystem paths and outbound network destinations. Review custom nodes as code with access to the runtime. Record how flows handle retries, idempotency, and message size so a compromised client cannot trigger repeated privileged actions.
Use the measurement as a queue
Start from the ZoomEye result, resolve ownership through DNS and cloud inventory, and test only authorized hosts. Compare the observed page with expected Node-RED assets. A 401 or login redirect for the editor does not automatically cover HTTP In paths, and a public flow endpoint does not prove the editor is exposed.
Log editor logins, deploy operations, node changes, and flow endpoint errors. Alert on configuration changes from a new source and unusual outbound destinations. If an editor was unintentionally accessible, remove the route, revoke active sessions and flow credentials supported by evidence, and review deploy history and target systems.
The 359 title matches are a discovery inventory. The meaningful next step is to enumerate the different HTTP surfaces and attach an owner, authentication decision, and bounded capability to each one.