Hardening n8n Webhooks Behind ALB and WAF

n8n webhooks are useful because they turn external events into automation. They are also one of the easiest ways to expose workflow logic directly to the internet. When n8n runs on ECS, an Application Load Balancer and AWS WAF can give you a cleaner security boundary before requests ever reach the container.

The goal is not to make every webhook private. The goal is to make each public webhook intentional, observable, and constrained.

Context

Problem: Public webhooks can be abused for spam, replay, brute force, and workflow-triggered data exfiltration. Approach: Put n8n behind ALB, terminate TLS there, enforce WAF rules, and design webhook workflows as untrusted intake. Outcome: The automation platform receives only traffic that passes basic edge controls and produces useful detection signals.

Control design

Start by separating editor access from webhook access. The editor should be restricted to trusted users, SSO, VPN, or an identity-aware proxy. Webhooks may need broader exposure, but they do not need the same routing policy.

Useful controls include:

• Dedicated hostname for inbound webhooks.
• TLS termination at ALB with modern policies.
• WAF managed rule groups for common web attacks.
• Rate limits for noisy webhook paths.
• Header or HMAC validation inside the workflow.
• Minimal response bodies so attackers do not get workflow detail.
• Access logs shipped to a security account or central log bucket.

The workflow should still verify the request. Edge controls reduce noise; they do not prove business legitimacy.

Implementation pattern

Use path routing to keep webhook traffic isolated from the editor.

automation.example.com/        -> restricted editor target group
hooks.example.com/webhook/*    -> webhook target group

If a SaaS provider supports signed callbacks, validate the signature as the first workflow step. If it does not, require a shared token, source allowlist, or a challenge handshake. Store those values in credentials or Secrets Manager, not in a visible workflow note.

Logging and detection

Webhook logging should answer practical blue-team questions:

• Which source IPs trigger the highest volume?
• Which webhook paths receive requests after being retired?
• Which requests fail signature validation?
• Which triggers lead to privileged downstream actions?
• Which payloads cause unusual execution time or error rates?

ALB access logs, WAF logs, n8n execution metadata, and downstream API audit logs should be correlated by request ID where possible.

Validation checklist

• Send a request without the required signature and verify the workflow exits early.
• Replay an old signed payload and confirm timestamp or nonce checks block it.
• Burst requests against a webhook and confirm WAF rate limits fire.
• Confirm editor routes are not reachable from the public webhook hostname.
• Review logs for the full request path from ALB to workflow execution.

Takeaways

Public webhook workflows should start from distrust. ALB and WAF provide the outer boundary, but the workflow still needs explicit authentication, replay protection, and telemetry.