Do you guys know a strategy to avoid flow tampering from the editor caused by evil plugins?
I created one for NRG Sentinel that doesn't use the editor, but I want to know if you know a reliable way to do it from the editor. Right now I believe it is impossible because an editor with plugins can't be trusted
Even if possible, it would not be a sensible security strategy.
Security assessments of a system must come from outside that system.
The sensible approach for something with a plugin/extension system is to fix what is installed and security vet every plugin/custom node. In addition, Node-RED must run under its own user id and group and ACL's should be enforced to limit its access to files and folders.
As I've said before, Node-RED is a generic compute platform. As such it is incredibly powerful and, just like allowing access to PowerShell, Python, Node.js, etc on a user workstation, it must be constrained if working in a controlled environment such as is typical for an enterprise setup.
Node-RED was created to be convenient even for novice users to use. It therefore does sacrifice some level of security because of that. Thankfully, this is relatively easy to fix using the tools available in the host OS.
I will reveal my solution that gets rid of these attacks later today. I just wanted to know if people had some suggestions.
Sentinel’s Safe Deployment mechanism introduces a controlled review process for all flow changes.
When a user deploys a flow, the server does not apply the changes immediately. Instead, the proposed deployment is placed into a Deployments Queue.
To review the changes, the user opens the dedicated review interface at:
/nrg/plugins/sentinel/deployments/review
This page runs in an isolated environment with no client-side plugins loaded, preventing any editor plugins from interfering with or tampering with the review process.
During the review, Sentinel presents every detected change in the deployment. The user must inspect and explicitly approve or reject each modification. Only after all changes are approved will the deployment be finalized and the new flow activated.
In addition to the isolated review interface, server-side protections enforce capability and permission restrictions to prevent plugins or nodes from modifying the deployment queue or bypassing the approval process.
This architecture ensures that no flow change can become active without explicit human approval, protecting the runtime from both client-side and server-side tampering.
This marks the beginning of the vision for Sentinel’s Flow Diff tool. Whenever a deployment is requested—whether from the client or the server—it is not applied immediately . Instead, Sentinel intercepts the request and places it into a deployment queue .
Rather than following the normal deployment path, the proposed changes must pass through Sentinel’s Safe Deployment review process . This ensures that every modification to a flow can be inspected and approved before it is activated in the runtime.
obs: I will probably create a separate list to show enqueued deployments in the editor.
Deployments queued waiting for approval
When the user clicks “Open review page” in the editor, they are redirected to Sentinel’s Deployment Review interface. This page runs in an isolated environment where no editor plugins are loaded, preventing rogue client-side plugins from tampering with the review process.
Sentinel breaks each deployment into a structured Approval Process composed of multiple review steps. Changes are organized and presented by Node, Tab, and Wires , allowing the user to inspect them in a controlled and understandable way. Each step provides the appropriate context for validation, including visual flow diffs and property diffs where relevant.
The reviewer must go through these steps sequentially , validating each change before moving forward. Only after the entire review process is completed and all changes are approved will the queued deployment be applied to the runtime.
This structured approval workflow ensures that any unintended or malicious modification—such as those introduced by a compromised or rogue plugin—can be detected and stopped before it affects the running flow.
obs: I'm going to update the looking and feel to match the editor's, and use the RED canvas to render the nodes and wires, when I finish the core features of Sentinel's Flow Diff tool.
Once all changes have been reviewed and approved, the user can proceed by clicking the Deploy button. At this point, a confirmation modal appears before the deployment is finalized.
By requiring this explicit review and confirmation workflow, NRG Sentinel ensures that no flow tampering can occur without the user noticing and approving the changes.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
