Securing n8n webhooks requires layered authentication because the default Webhook node, while supporting Basic Auth, Header Auth, and JWT built‑in modes, does not natively verify payload integrity or prevent replay attacks. HMAC‑SHA256 signatures cryptographically bind each request to a shared secret, proving authenticity and detecting tampering. Complementary layers—IP allowlisting, raw body capture, timing‑safe comparison, and community security nodes—combine to close gaps that any single method leaves open. This guide details every verification layer with production‑grade implementation patterns [1].

How do you implement HMAC‑SHA256 signature verification for n8n webhooks?

Enable Raw Body on the Webhook node so the original byte‑for‑byte payload is preserved, then chain three downstream nodes: a Code node extracts the raw binary and decodes it into a UTF‑8 string; a Crypto node recomputes the HMAC‑SHA256 hash over timestamp.rawBody using the shared secret; and a second Code node performs timing‑safe comparison via crypto.timingSafeEqual(). [1]

The canonical six‑layer security chain (Webhook with Header Auth + Raw Body → extract raw body → Crypto computes HMAC‑SHA256 → timing‑safe comparison → strict payload whitelist validation → business logic) ensures that authentication, integrity, freshness, and structure are all verified before any workflow action executes [1]. Invalid requests immediately receive 403 Forbidden (signature/timestamp failure) or 400 Bad Request (payload validation failure), with no response body to avoid leaking internal logic. For replay protection, include a timestamp and optional nonce in the signed payload—the Code node rejects any request older than a configurable window (default: 5 minutes). The community Secure Webhook node (@prokodo/n8n-nodes-secure-webhook) bundles all six layers—plus IP allow/deny (CIDR), per‑IP rate limiting, mTLS header checks, and Redis HA support—into a single hardened trigger that supports both raw‑body HMAC (sha256 or sha512) and extended signatures covering method, path, query, timestamp, nonce, and bodyhash [4]. For complete credential‑level security patterns across all node types, see the n8n Credential Nodes guide.

When should you use Basic Auth, Header Auth, or JWT for n8n webhook authentication?

n8n provides four built‑in authentication methods on the Webhook node: Basic Auth for username‑password pairs sent as Base64‑ encoded credentials in the Authorization header; Header Auth for custom header‑name‑and‑value checks ideal for API key scenarios; JWT Auth for bearer‑token validation supporting OIDC‑ compatible identity providers; and None for public endpoints [2].

These methods verify who is calling but do not verify payload integrity, freshness, or structure— a Header‑Auth‑protected webhook still accepts a tampered body. Choose Header Auth when integrating with internal APIs or services that send a static API key in a custom header; use Basic Auth for simple password‑protected endpoints; and prefer JWT Auth for service‑to‑service authentication where tokens carry expiration claims. For query‑parameter‑based authentication, a GET Webhook can validate a secret parameter (e.g., ?secret=abc123) via an IF node at the workflow start, though this is less secure than header‑based methods because secrets appear in server logs [5]. The JWT credential type also supports issuing custom tokens for n8n‑native authentication patterns — users can issue a signed token, generate a QR code for convenience, and validate it inside workflows without external identity providers [6]. For the complete security model covering OAuth2 flows and credential encryption, see the n8n Credential Nodes guide.

How do you configure IP allowlisting for n8n webhook nodes and what are its limits?

In the Webhook node’s Options panel, add comma‑separated CIDR ranges like 34.195.0.0/16, 54.208.0.0/15 to the IP(s) Allowlist field. n8n rejects any request whose source IP does not match an entry. For platforms like Stripe, GitHub, and Zendesk that publish fixed IP ranges, this adds a network‑layer filter before authentication logic runs [2].

A critical vulnerability underscores the limits of IP‑only protection: CVE‑2025‑68949 (CVSS 5.3 MEDIUM) affected n8n versions 1.36.0 through <2.2.0, where the Webhook node’s IP whitelist performed partial string matching instead of exact IP comparison. An attacker whose IP shared a partial prefix with a whitelisted address could bypass restrictions—both IPv4 and IPv6 were impacted [3]. The fix shipped in version 2.2.0, which implements strict IP comparison logic. Always upgrade if you rely on IP allowlisting, and never use it as the sole security layer—layer it with HMAC signatures or JWT authentication. For self‑hosted instances behind a reverse proxy, set N8N_PROXY_HOPS=1 so n8n correctly identifies the real client IP rather than the proxy’s IP. For the complete hardening blueprint combining IP filters with cryptographic verification, see the n8n Node Security Hardening guide.

How do you validate webhook payload integrity with HMAC‑SHA256 signatures?

Payload integrity validation ensures the request body has not been altered in transit. The sender computes an HMAC‑SHA256 signature over the raw request body using a pre‑shared secret and attaches it as a header (e.g., x‑signature, x‑hub‑signature‑256, or x‑chatworkwebhooksignature). n8n recomputes the signature from the received raw body and compares the two values using constant‑time comparison [2].

The two most common implementation pitfalls are hashing parsed JSON instead of the raw body (even minor whitespace differences invalidate the signature) and using simple string equality (===) instead of crypto.timingSafeEqual(), which is vulnerable to timing attacks. For production, extend the signature to include a timestamp to prevent replay attacks (reject requests older than 5 minutes) and optionally a nonce for one‑time use. Several 2026 CVEs highlight the criticality of this layer: CVE‑2026‑22948 (Zendesk Trigger node, fixed in ≥2.6.2), GHSA‑mqpr‑49jj‑32rc (GitHub Trigger node, fixed in ≥1.123.18/≥2.10.1), and CVE‑2026‑21894 (Stripe Trigger node, fixed in ≥2.2.2) all involved failures to verify HMAC signatures on service‑specific trigger nodes, allowing forged payload injection [3]. For a complete implementation template, see the n8n Webhook Node Configuration guide.

How do you protect n8n webhook URLs from unauthorized discovery and forgery?

Each webhook URL contains a high‑entropy UUID that is unguessable, but authenticated n8n users with workflow access can view it. Never expose the URL in public documentation, git repositories, or client‑side JavaScript. Rotate the webhook URL by deleting and recreating the node if the URL is ever leaked externally [5].

For self‑hosted deployments, set N8N_HOST=127.0.0.1 to bind n8n to the loopback interface, then place a reverse proxy (Nginx or Caddy) in front that terminates HTTPS and forwards X‑Forwarded‑For and X‑Forwarded‑Proto headers. Set N8N_PROXY_HOPS=1 so n8n trusts the proxy headers and generates correct webhook URLs with https:// rather than http://. For an additional layer, restrict webhook endpoints by IP at the network level and enforce authentication for all public webhooks—the 2026 n8n threat landscape shows that publicly exposed webhooks are a primary attack vector for workflow injection [8]. For complete self‑hosted hardening covering firewall rules, Basic Auth, and Nginx configuration, see the n8n Node Security Hardening guide.

How do you combine HMAC, auth headers, IP allowlisting, and community nodes for defense‑in‑depth?

Layer IP allowlisting first at the network level to reject unknown sources immediately. Then validate the HMAC‑SHA256 signature to confirm the payload hasn’t been tampered with and is fresh. Finally, use Header Auth or JWT to identify the specific tenant or sender. This layered pattern creates defense‑in‑depth—each layer blocks a different attack vector and no single failure compromises security [4].

For high‑security environments, the community Secure Webhook node (@prokodo/n8n-nodes-secure-webhook) bundles all layers into a single hardened trigger: HMAC (raw‑body or extended signature), JWT/JWKS, API Key, or Combo (HMAC + IP allow/deny by CIDR), plus replay protection with timestamp + nonce (one‑time use), per‑IP rate limiting (in‑memory token bucket or Redis Lua fixed‑window), mTLS awareness via proxy headers, and external HTTPS audit export of accept/reject metadata [4]. For teams who prefer to implement these layers manually with n8n’s stock nodes, the HMAC template provides the complete six‑layer chain [1]. For monitoring blocked requests and integrating with incident response pipelines, see the n8n DevOps Nodes guide.