Your n8n Webhook URL Is a Password — And You've Probably Pasted It Somewhere Public

Description and use

n8n webhook URLs act as bearer tokens that can be inadvertently exposed in screenshots, exported JSON, or logs. The author discovered an unauthorized workflow run and implemented a two‑layer defense: enable Header Auth and verify an HMAC signature in the first Code node before any side effects.

Problem

Webhook URLs in n8n are bearer tokens that can be accidentally exposed in screenshots, exported JSON, or logs, allowing unauthorized execution of workflows.

Outcome

Unauthorized executions were prevented by treating webhook URLs as secrets, adding Header Auth, and verifying HMAC signatures before any side effects.

Workflow

• 1. Enable Header Auth on the Webhook node or use a caller‑provided HMAC signature.
• 2. In the first Code node after the Webhook trigger, verify the signature against the raw body using timingSafeEqual.
• 3. Throw an error and halt the workflow if verification fails.
• 4. Store signing secrets in environment variables ($env) instead of workflow JSON.
• 5. Use the test URL during development and switch to production only at ship time.
• 6. Rotate the webhook path immediately if a leak is suspected.
• 7. Avoid posting screenshots, exports, or logs that contain live production webhook URLs.

Evidence

An n8n webhook URL is a bearer token. Whoever holds it can trigger your workflow.

Source

The full production URL was right there in the screenshot, readable at full resolution.

Source

Header Auth works when you choose the secret. But when the caller is Stripe, Shopify, or a client's store, they sign the payload instead — typically HMAC-SHA256 of the raw body with a signing secret, sent in a header.

Source

Three details matter here: verify against the raw body, compare with timingSafeEqual, and throw before any side effect in the workflow touches the payload.

Source