What Static Review Can Catch in an Exported n8n Workflow Before Production

VIKTUNCODED — Thu, 13 Aug 2026 10:33:55 +0000

Automation workflows can execute successfully and still be difficult to review.

A successful run tells you that the nodes and connections worked for that input. It does not always make it obvious what an external input can reach, where validation happens, or whether a credential reference is hidden inside an inline sub-workflow.

What static review can reveal

An exported workflow JSON contains useful structure for a first review pass:

external triggers and reachable paths;
unvalidated input moving toward sensitive nodes;
credential references that are easy to miss during a visual review;
duplicate node names, dangling edges, and malformed shapes;
inline sub-workflows whose permission boundaries are unclear.

A simple example is a public webhook connected through a few transformations to an HTTP request or another sensitive action. If there is no clear validation boundary, the important question is not only “does the workflow run?” but also “what can this input reach?”

Why local-first review matters

Workflow exports can contain sensitive structure and credential-shaped values. For a first-pass review, sending those exports to a remote service is not always necessary.

A client-side analyzer can keep the report in the browser, redact secret-shaped values in evidence, and let the reviewer decide what sanitized information to share. This does not replace a full security review, but it reduces the amount of data that needs to leave the local environment.

n8n Workflow Guard

I built n8n Workflow Guard as a small, local-first review assistant for exported n8n workflow JSON.

It produces deterministic findings with evidence paths and supports JSON and SARIF export. The repository includes sanitized fixtures, input-safety limits, cycle detection, malformed-shape and duplicate-node diagnostics, secret redaction, and 16 analyzer tests.

The goal is explainability: a reviewer should be able to see why a finding exists and where it came from instead of receiving only an opaque score.

The boundary is intentional

The project does not connect to a live n8n instance, request API keys, upload workflow data, load remote fonts, or run analytics. It is not an exploit tool and it is not a replacement for n8n’s own security controls or human verification.

It is a narrow static review pass over an exported JSON file.

Looking for real edge cases

I am interested in sanitized workflow shapes that produce false positives or reveal a missing rule. Reproducible examples and concrete criticism are more useful than generic praise.

Repository: https://github.com/viktuncoded/n8n-workflow-guard