Security

Overview

Security measures exposure of credentials and unauthenticated public entry points. It's narrower than a full security audit: FlowScan reads exported JSON, not infrastructure or runtime behavior, so it checks for the two exposure patterns that are directly visible in workflow structure — without any deeper access — and that show up constantly in real exports.

How this affects your score

Security is weighted 0.10. Findings range from medium to critical severity — hardcoded secrets sit at the higher end because the exposure is immediate and complete the moment the workflow JSON leaves the platform.

Worked example: a workflow with one critical finding (a hardcoded API key in a node parameter) scores 100 − 30 = 70 on Security, contributing 70 × 0.10 = 7.0 points toward the total.

Findings

Unauthenticated webhook

Severity: medium → high. By default, a webhook URL is just a URL — anyone who has it, or guesses it, can send it a request. This finding escalates based on two things: what the webhook leads to, and how guessable its path is. An unauthenticated webhook that only triggers a read and a notification is a nuisance-level risk; one that triggers a write — especially with no idempotency guard behind it — means anyone with the URL can trigger that write repeatedly, on demand. A short or predictable path (/webhook/new-order) is easier to find than a generated UUID, which also factors into severity.

Example: a webhook at /webhook/create-invoice has no authentication and triggers an invoice creation with no de-dupe guard; anyone who discovers the path can trigger invoice creation repeatedly.

Fix: add authentication — header-based auth or a shared-secret check as the first node after the trigger — to any webhook that isn't intentionally public, and regenerate predictable paths to non-guessable values.

Hardcoded secrets in node parameters

Severity: high → critical. API keys, bearer tokens, and passwords typed directly into a node's static parameters instead of stored in the platform's credential system. Both n8n and Make provide dedicated credential storage specifically so secrets don't end up sitting in plain text inside the workflow definition — but it's a common shortcut, especially for a quick HTTP Request node hitting an API without a dedicated node type.

Example: an HTTP Request node has an API key typed directly into a header parameter instead of referenced through a stored credential; the moment this workflow is exported, shared, or backed up, the key travels with it in plain text.

Fix: move every hardcoded secret into the platform's credential manager. This is usually a small edit per node and is the highest-value fix in this category — it closes an exposure that's otherwise complete and immediate.

Recommended fixes

1. Move all hardcoded secrets into credential storage — the single highest-value fix, since the exposure is total and immediate until fixed.
2. Add authentication to any webhook that isn't intentionally public-facing.
3. Regenerate predictable webhook paths, especially on webhooks that lead to a write.
4. Before sharing or exporting any workflow JSON for any reason — including running it through an analyzer — check for both of these patterns first, or use a sanitizer that strips secrets locally before the file leaves your machine.

Related categories

• Reliability — an unauthenticated webhook with no de-dupe guard is both a security and a reliability gap
• Observability — what should be logged once a webhook-triggered write happens
• Overview — how this category's weight compares to the other six