Webhook Security & Multi-Tenant Authentication

Questions
1

Hi everyone I’m facing security challenges in a multi-tenant n8n webhook architecture where different clients send requests to shared webhook endpoints.
The main issue is securely validating and isolating tenant requests while preventing:
• Unauthorized webhook access
• Credential spoofing
• Replay attacks
• Cross-tenant data exposure
• API abuse and spam requests
Since workflows dynamically load tenant credentials during execution, I need a secure authentication and verification layer that scales under high webhook traffic.
const crypto = require(“crypto”);
const signature = crypto
.createHmac(“sha256”, tenantSecret)
.update(payload)
.digest(“hex”);
if (signature !== incomingSignature) {
throw new Error(“Invalid webhook signature”);
}

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hi @Kabrooks you can build a strong security layer around all webhook requests before they reach the workflows.

The goal is to make sure:
Only authorized clients can trigger workflows
Each tenant’s data stays isolated
Fake or duplicate requests are blocked
The system remains secure even under high traffic

My solution includes:
Using HMAC signature verification to confirm requests are genuine
Assigning each tenant a unique secret key
Validating timestamps to stop replay attacks
Adding rate limiting to prevent spam or abuse
Encrypting credentials before storing them
Isolating workflow executions per tenant

This creates a safer and more scalable multi-tenant webhook system.

A security validation like this: const crypto = require(“crypto”);

const expectedSignature = crypto
.createHmac(“sha256”, tenantSecret)
.update(payload)
.digest(“hex”);

if (expectedSignature !== incomingSignature) {
throw new Error(“Unauthorized request”);
}

This code checks whether the incoming webhook request was actually sent by the correct client.

3

Welcome @Kabrooks to our community! I’m Jay and I am a n8n verified creator.

The key piece Emmas’ reply doesn’t cover is how to actually fetch the tenantSecret dynamically in your n8n Code node. The pattern I use: at the start of the webhook workflow, take the tenant identifier from the request (header, path param, or payload field), do an HTTP Request or Postgres node lookup to fetch that tenant’s secret from your DB, then run the HMAC check in the next Code node using that fetched value.

For replay protection, add a timestamp field to the incoming request and validate it in the same Code node:

const requestTime = parseInt($input.first().json.body.timestamp);
if (Date.now() - requestTime > 300000) throw new Error("Request expired");

This gives you a 5-minute replay window. Combined with the HMAC check, unauthorized and replayed requests get rejected before any workflow logic runs. Rate limiting is harder to do natively in n8n - for high-traffic scenarios, handle that at the reverse proxy layer (nginx, Cloudflare) rather than inside the workflow.

4

hey @Kabrooks
check if this package works for you @prokodo/n8n-nodes-secure-webhook

5

Emmas and Jay covered the inbound half well, HMAC plus a per-tenant secret fetched at runtime is the right shape for verifying who’s calling.

The part that usually bites later is the other direction. Once the request is verified, the workflow still has to act on that tenant’s downstream services (their HubSpot, Google, whatever), and Jay’s “fetch the secret from the DB into a Code node” pattern means the raw tenant credential sits in execution memory for the length of the run. With shared workflows under high traffic that’s exactly where cross-tenant exposure creeps in. One logging mistake, or a node that echoes its input, and tenant B’s token ends up in tenant A’s run.

The pattern that holds up better is not letting the workflow hold the raw downstream credential at all. Keep an opaque per-tenant reference in the workflow, then resolve and inject the real credential at egress, outside the execution context. A per-key audit trail then tells you which tenant hit which service and when, which is usually what the “cross-tenant data exposure” worry actually needs to be answerable.

Inbound verification stays exactly as Emmas and Jay described. This is just the egress side.

Full disclosure, I work on an open-source gateway (NyxID) that does this egress resolution and injection, which is why I have opinions here. repo if useful: github.com/ChronoAIProject/NyxID

6

Thanks so much guys for the reply