Your n8n Webhook URL Is a Password — And You've Probably Pasted It Somewhere Public
说明与用途
n8n 的 Webhook URL 充当 bearer token,若被意外泄露(如截图、导出 JSON 或日志),可导致未授权执行。作者发现一次未授权运行后,实施两层防护:开启 Header Auth 并在第一个 Code 节点中验证 HMAC 签名,确保在任何副作用之前完成验证。
问题
Webhook URLs in n8n are bearer tokens that can be accidentally exposed in screenshots, exported JSON, or logs, allowing unauthorized execution of workflows.
结果
Unauthorized executions were prevented by treating webhook URLs as secrets, adding Header Auth, and verifying HMAC signatures before any side effects.
工作流
- 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.
证据
An n8n webhook URL is a bearer token. Whoever holds it can trigger your workflow.
The full production URL was right there in the screenshot, readable at full resolution.
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.
Three details matter here: verify against the raw body, compare with timingSafeEqual, and throw before any side effect in the workflow touches the payload.
- 记录日期: 2026-10-18T06:41:04.112Z