PR #29825: fix(Webhook Node): Add opt-out for sensitiveOutputFields masking

• Repository: n8n-io/n8n
• Author: ChrisJr404
• State: open | merged: False
• Link: https://github.com/n8n-io/n8n/pull/29825

Description (problem / solution / changelog)

Summary

Closes #29819.

The Webhook node hardcodes sensitiveOutputFields: ['headers.authorization', 'headers.cookie'], which NodeDefinedFieldRedactionStrategy applies unconditionally — even on the reveal path and even when the workflow's redaction policy is none. The redacted dict propagates to downstream nodes as runtime data, so workflows that previously read the auth header for JWT signature verification, HMAC verification, or Bot Framework token validation break on upgrade. There is currently no per-workflow or per-node opt-out short of disabling the entire redaction module instance-wide.

This PR adds a node-instance-scoped escape hatch so the security-by-default behaviour stays in place for every existing workflow, while users with a legitimate need to inspect the raw auth header can opt their specific Webhook node in.

Use case

The motivating example from the issue: validating a Microsoft Bot Framework JWT against the published JWKS in a Code node. The Bot Framework signs every inbound request with a JWT in the Authorization header, and the bot is required to verify that signature before responding. The same shape applies to Slack, GitHub, Stripe, and Shopify HMAC verifications and any pattern where a downstream node reads the bearer token or the Cookie header as a string.

Design

A two-piece change in the redaction protocol:

1. INodeTypeDescription.sensitiveOutputFieldsOptOutPath?: string (packages/workflow). A node author may declare a dot-notation path on INode.parameters. When that path resolves to strictly the boolean true on a given node instance, NodeDefinedFieldRedactionStrategy.buildSensitiveFieldsMap skips that node when building the redaction map.

   • Opt-in by node author: every existing node leaves the field unset, so the prior "always redacted, never revealable" guarantee continues to hold for all of them.
   • Opt-in by node instance: even on a node that declares the path, the per-instance default is to redact.
   • Fail-safe: missing keys, non-record intermediates, falsey values, and truthy non-booleans (e.g. the string "true") all leave redaction enabled.

2. Webhook node (packages/nodes-base/nodes/Webhook). The Webhook node sets sensitiveOutputFieldsOptOutPath: 'options.exposeAuthHeaders' and adds an Expose Authentication Headers boolean inside its existing Options collection, defaulted to false. The option's description spells out the security trade-off (anyone with execution-read access on the workflow will see the headers in execution data).

Parameter UI shape

{
    displayName: 'Expose Authentication Headers',
    name: 'exposeAuthHeaders',
    type: 'boolean',
    default: false,
    description:
        "Whether to keep the Authorization and Cookie request headers in this node's output instead of redacting them. Enable only when downstream nodes need the raw values (e.g. JWT signature or HMAC verification). Anyone with execution-read access on the workflow will be able to see these headers in execution data.",
},

The opt-out is wired into the description as:

sensitiveOutputFields: ['headers.authorization', 'headers.cookie'],
sensitiveOutputFieldsOptOutPath: 'options.exposeAuthHeaders',

Why this shape over the alternatives in the issue

The issue suggests three approaches in priority order. I went with #2 (node-level toggle) for these reasons:

• #1 (honour workflow Do not redact) would walk back the explicit guarantee from #26546 that node-declared sensitive fields are always redacted regardless of workflow policy. Workflow-level redaction settings and node-author-declared sensitive fields are deliberately decoupled so that "redact most fields but reveal everything in this workflow" remains a coherent permission model. Tying the two together would change the semantics for every node, not just Webhook.
• #3 (typeVersion bump that defaults pre-existing instances to un-redacted) would silently un-redact existing webhooks on upgrade, which is a lateral regression from the user perspective: workflows that should keep redacting headers (the security default the original PR was added for) suddenly stop. A typeVersion bump where the new version defaults to redacting and the old version defaults to un-redacting would also leak the old behaviour forever for any pre-2.18 webhook, undoing the fix.
• #2 (node-level toggle) preserves security-by-default for every existing instance, surfaces the trade-off in the UI text, and keeps the opt-out scoped to the one node-instance that needs it. Generic enough that other nodes can opt in to the same pattern without each baking their own toggle plumbing.

Test coverage

packages/cli/src/modules/redaction/executions/strategies/__tests__/node-defined-field-redaction.strategy.test.ts (sensitiveOutputFieldsOptOutPath describe block, 5 new cases):

1. skips redaction when the per-instance opt-out parameter is true — happy path: opt-out true leaves headers.authorization as the original Bearer secret string.
2. still redacts when the opt-out parameter is false — explicit-false still redacts to the marker.
3. still redacts when the opt-out parameter is missing entirely (default) — missing key still redacts.
4. still redacts when the opt-out parameter is a truthy non-boolean (fail-safe) — string "true" does not opt out.
5. does not affect other nodes that lack an opt-out path on their description — a Webhook with the opt-out path opts out, while a sibling node without the path on its description keeps redacting even when the parameter is set on its instance.

packages/nodes-base/nodes/Webhook/test/Webhook.test.ts (sensitiveOutputFields describe block, 2 new cases):

1. declares the opt-out parameter path so users can expose auth headers when needed — asserts description.sensitiveOutputFieldsOptOutPath === 'options.exposeAuthHeaders'.
2. exposes the opt-out as a boolean option, defaulted to false (security-by-default) — asserts the new option exists in the Options collection with type: 'boolean' and default: false.

Local results:

• pnpm --filter n8n-nodes-base test -- nodes/Webhook — 64/64 passed.
• pnpm --filter n8n test -- modules/redaction — 87/87 passed (all 4 redaction suites including the strategy and orchestrator).
• pnpm build --filter='n8n-workflow', --filter='n8n-nodes-base', --filter='n8n' — all green.
• eslint nodes/Webhook — 0 errors.

Related Linear tickets, Github issues, and Community forum posts

• Closes https://github.com/n8n-io/n8n/issues/29819
• Original feature: #26546 (sensitiveOutputFields strategy pipeline)
• Earlier opt-in attempt: #20783 (closed; went the other direction — opt-in redaction)
• Community: https://community.n8n.io/t/headers-redaction-for-webhooks-output-to-cut-out-auth-data/230083 / https://community.n8n.io/t/how-do-we-redact-the-headers-that-are-sent-to-the-webhook-trigger-node/205437

Review / Merge checklist

• PR title and summary are descriptive.
• Docs updated or follow-up ticket created. Suggested doc edit: add a paragraph to https://docs.n8n.io/workflows/executions/execution-data-redaction/ noting the Webhook node now exposes a per-instance Expose Authentication Headers toggle for downstream JWT/HMAC verification.
• Tests included.
• PR Labeled with release/backport (worth considering — the regression breaks Bot Framework / HMAC / Stripe / Shopify webhooks on upgrade).

Changed files

• packages/cli/src/modules/redaction/executions/strategies/__tests__/node-defined-field-redaction.strategy.test.ts (modified, +197/-2)
• packages/cli/src/modules/redaction/executions/strategies/node-defined-field-redaction.strategy.ts (modified, +33/-2)
• packages/nodes-base/nodes/Webhook/Webhook.node.ts (modified, +1/-0)
• packages/nodes-base/nodes/Webhook/description.ts (modified, +8/-0)
• packages/nodes-base/nodes/Webhook/test/Webhook.test.ts (modified, +18/-0)
• packages/workflow/src/interfaces.ts (modified, +13/-0)