Rate‑Limit Your n8n Webhook After Signature Verification, Not Before

Description and use

Signature verification must precede rate limiting; the limiter should use the verified sender identity and a shared Redis counter to guard against DoS attacks and support scaling.

Problem

A leaked n8n webhook URL can be abused to flood the endpoint, especially if rate limiting is applied before HMAC signature verification, allowing attackers to consume the limiter bucket with garbage requests.

Outcome

By verifying signatures before applying rate limits and keying the limiter on verified sender identity, the workflow protects against DoS attacks while ensuring legitimate traffic is not throttled.

Workflow

• 1. Receive webhook request via n8n Webhook node.
• 2. Verify HMAC signature using the shared secret and timingSafeEqual on the raw body.
• 3. If verification fails, throw an error and terminate the workflow (bucket untouched).
• 4. If verification succeeds, check the rate‑limit counter keyed by the verified sender identity (e.g., delivery ID, API key, tenant ID).
• 5. If the counter exceeds the allowed threshold, reject the request; otherwise, increment the counter and proceed with the workflow.
• 6. For path/secret rotation, immediately deactivate the old path, accept both old and new secrets during a grace window, then drop the old secret after the window.
• 7. Optionally, place a Cloudflare or similar front‑end for volumetric protection, but keep the post‑verification limiter for per‑sender control.

Evidence

If the rate limiter runs first: 1. The attacker burns through the bucket with garbage requests. 2. Legitimate callers — your client's store sending real order events — start getting dropped.

Source

Run verification first and the math flips: garbage requests die at the signature check, cost nothing from the bucket, and the limiter only ever sees requests that already proved they're from a real caller.

Source

Keying by IP brings the shared‑fate problem back in another form. NAT'd offices put dozens of users behind one address; serverless egress ranges do the same at cloud scale.

Source

Rotate the path and the secret together. A new path with the old secret is theater — every previously captured signed payload still verifies against the new URL.

Source