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

Описание и применение

Проверка подписи вебхука должна происходить до применения ограничения частоты, а лимитер должен использовать проверенную идентификацию отправителя и храниться в Redis, чтобы защитить от DoS‑атак и обеспечить корректную работу при масштабировании.

Задача

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.

Результат

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.

Рабочий процесс

• 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.

Доказательства

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.

Источник

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.

Источник

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.

Источник

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.

Источник