Webhooks verstehen und absichern

Ein Webhook ist im Kern eine offene Tür in Deinem n8n-System: Sobald ein externer Dienst eine HTTP-Anfrage an die vom Webhook-Node erzeugte URL schickt, startet der zugehörige Workflow automatisch, ganz ohne Zeitplan und ohne manuellen Klick. Genau diese Offenheit macht Webhooks so nützlich für Integrationen mit Stripe, GitHub, Formular-Tools oder eigenen Anwendungen. Sie macht die URL aber auch zu einem Angriffspunkt, wenn keine Authentifizierung, kein IP-Filter und keine Signaturprüfung dazwischenstehen. Wer die URL kennt oder errät, kann den Workflow auslösen.

Dieser Artikel zeigt den Aufbau des Webhook-Node in n8n, die eingebauten Authentifizierungsmethoden, das IP-Whitelisting als zusätzliche Schutzschicht und die Konfiguration hinter einem Reverse Proxy, ein Punkt, der bei selbst gehosteten n8n-Instanzen regelmäßig für Verwirrung sorgt. Stand: Juli 2026.

Wie der Webhook-Node aufgebaut ist

Laut der n8n-Dokumentation zum Webhook-Node unterstützt der Node sechs HTTP-Methoden: DELETE, GET, HEAD, PATCH, POST und PUT. Im Feld Path legst Du den Pfad der URL fest, entweder frei oder mit Platzhaltern wie `/:variable` für dynamische Segmente. Ohne eigene Eingabe generiert n8n einen zufälligen Pfad, was Kollisionen mit anderen Workflows vermeidet.

Für die Antwort gibt es mehrere Optionen:

• Immediately: Der Webhook antwortet sofort mit der Nachricht, dass der Workflow gestartet wurde, ohne auf dessen Ende zu warten.
• When Last Node Finishes: Die Antwort enthält die Daten des letzten ausgeführten Node.
• Using Respond to Webhook Node: Ein eigener Node im Workflow steuert Status-Code, Header und Body der Antwort gezielt.
• Streaming response: Für Nodes mit Streaming-Unterstützung lässt sich die Antwort in Echtzeit übertragen.

Wichtig für die Praxis: n8n registriert laut Dokumentation nur eine Kombination aus Pfad und HTTP-Methode gleichzeitig. Zwei aktive Workflows mit demselben Pfad und derselben Methode blockieren sich gegenseitig, einer muss deaktiviert oder der Pfad beziehungsweise die Methode geändert werden.

Authentifizierung direkt im Webhook-Node

Bevor Du über IP-Filter oder Reverse-Proxy-Regeln nachdenkst, solltest Du die eingebaute Authentifizierung des Webhook-Node nutzen. Laut der Dokumentation zu Webhook-Credentials stehen vier Optionen zur Wahl:

• Basic Auth: Der aufrufende Dienst muss Benutzername und Passwort im Authorization-Header mitschicken. Einfach einzurichten, aber ohne zusätzliche Verschlüsselung nur in Kombination mit HTTPS sinnvoll.
• Header Auth: Du legst einen Header-Namen fest, zum Beispiel `X-API-Key`, und einen geheimen Wert. n8n prüft jede eingehende Anfrage auf genau diesen Header. Diese Methode passt gut zu Diensten, die ohnehin einen API-Key mitschicken.
• JWT Auth: Die Anfrage muss ein digital signiertes JSON Web Token enthalten. n8n verifiziert die Signatur über eine Passphrase oder einen PEM-Key, den Du im Credential hinterlegst.
• None: Keine Prüfung, jede Anfrage mit korrektem Pfad wird angenommen. Diese Einstellung eignet sich höchstens für kurze Tests, nicht für produktive Workflows.

Die Doku macht dabei einen wichtigen Punkt klar: Die gewählte Methode muss zu dem passen, was der aufrufende Dienst tatsächlich mitschickt. Ein GitHub-Webhook etwa signiert Anfragen typischerweise per HMAC-Signatur im Header, was Du zusätzlich zur Header Auth in einem Code-Node prüfen kannst, wenn Du über die reine Node-Authentifizierung hinaus absichern willst.

IP-Whitelisting als zusätzliche Schutzschicht

Zusätzlich zur Authentifizierung bietet der Webhook-Node die Option IP(s) Whitelist. Du trägst dort eine kommagetrennte Liste erlaubter IP-Adressen ein, laut Dokumentation antwortet n8n Anfragen von nicht gelisteten Adressen mit einem 403-Fehler. Bleibt das Feld leer, sind alle Adressen zugelassen.

In der Praxis funktioniert IP-Whitelisting am besten als zweite Schicht neben Header Auth oder JWT Auth, nicht als alleinige Absicherung: Kennt ein Dienst wie Stripe oder GitHub feste Absende-IP-Bereiche, trägst Du diese ein und blockierst damit alles andere von vornherein. Bei Diensten mit wechselnden oder unklaren IP-Bereichen bleibt die Header- oder JWT-Prüfung die verlässlichere Methode. So behältst Du die Kontrolle darüber, wer den Workflow überhaupt erreichen kann, bevor die eigentliche Logik zu laufen beginnt.

Webhooks hinter einem Reverse Proxy richtig konfigurieren

Läuft n8n selbst gehostet hinter einem Reverse Proxy, etwa Caddy, Nginx oder Traefik, funktioniert die automatische URL-Erkennung nicht mehr zuverlässig: n8n läuft intern meist auf Port 5678, während der Proxy die Anwendung über Port 443 nach außen zeigt. Laut der n8n-Dokumentation zur Webhook-URL-Konfiguration hinter einem Reverse Proxy löst Du das mit zwei Umgebungsvariablen:

• WEBHOOK_URL: Legt die vollständige, öffentlich erreichbare Adresse fest, die n8n im Editor anzeigt und bei externen Diensten registriert, etwa `https://n8n.beispiel.de/`.
• N8N_PROXY_HOPS: Muss auf die Anzahl der vorgeschalteten Proxies gesetzt werden, üblicherweise 1. Damit interpretiert n8n die von einem Proxy weitergereichten Header korrekt.

Der Proxy selbst muss dafür die Header `X-Forwarded-For`, `X-Forwarded-Host` und `X-Forwarded-Proto` durchreichen. Fehlt diese Konfiguration, kann das IP-Whitelisting aus dem vorigen Abschnitt ins Leere laufen, denn n8n sieht dann nur die interne Proxy-Adresse statt der tatsächlichen Absender-IP. Genau dieser Zusammenhang ist laut n8n-Dokumentation eine der häufigsten Fehlerquellen: Whitelisted IPs werden abgelehnt, obwohl die Liste korrekt gepflegt ist, weil N8N_PROXY_HOPS fehlt oder falsch gesetzt wurde.

Test- und Produktions-URL nicht verwechseln

Jeder Webhook-Node erzeugt zwei unterschiedliche URLs. Die Test-URL zeigt eingehende Daten im Editor an, sobald Du im Node auf Listen for Test Event klickst, bleibt dabei aber laut Dokumentation nur 120 Sekunden aktiv. Die Produktions-URL greift erst, wenn der Workflow veröffentlicht wird, zeigt Daten dann aber nicht mehr im Editor, sondern ausschließlich im Tab Executions.

Ein typischer Fehler in der Praxis: Ein externer Dienst wird während der Entwicklung auf die Test-URL konfiguriert, weil sie im Editor sichtbares Feedback liefert. Nach der Veröffentlichung des Workflows läuft der Webhook dann ins Leere, weil der Dienst weiterhin die alte Test-URL statt der Produktions-URL anspricht. Prüfe deshalb vor jedem Go-Live, ob wirklich die Produktions-URL im aufrufenden System hinterlegt ist. Wer n8n als selbst gehostete digitale Mitarbeiterin einsetzt und dabei Wert auf saubere, nachvollziehbare Webhook-Absicherung legt, findet in der n8n-Beratung von NordFlux Unterstützung bei Aufbau, Authentifizierung und Reverse-Proxy-Konfiguration.

Häufige Fragen

Reicht Header Auth allein als Absicherung für einen Webhook?

Für viele interne Automatisierungen ist Header Auth über HTTPS ausreichend, solange der geheime Wert lang genug und nicht erratbar ist. Bei sicherheitskritischen Integrationen, etwa Zahlungsanbietern, empfiehlt sich zusätzlich IP-Whitelisting oder eine Signaturprüfung wie HMAC in einem nachgeschalteten Code-Node.

Warum wird meine whitelisted IP-Adresse trotzdem blockiert?

Meist liegt es an einem fehlenden oder falsch gesetzten N8N_PROXY_HOPS, wenn n8n hinter einem Reverse Proxy läuft. Ohne diese Variable sieht n8n nicht die tatsächliche Absender-IP, sondern die interne Adresse des Proxys, und vergleicht diese fälschlicherweise mit der Whitelist.

Kann ich mehrere Workflows auf denselben Webhook-Pfad legen?

Nein, laut n8n-Dokumentation lässt sich pro Kombination aus Pfad und HTTP-Methode nur ein Webhook gleichzeitig registrieren. Für mehrere Auslöser auf demselben Pfad musst Du unterschiedliche HTTP-Methoden nutzen oder den Pfad anpassen.

Was passiert, wenn ich die Test-URL nach der Entwicklung weiterverwende?

Die Test-URL ist nur für 120 Sekunden nach dem Klick auf Listen for Test Event aktiv und zeigt Daten im Editor an. Nach der Veröffentlichung des Workflows müssen aufrufende Systeme auf die Produktions-URL umgestellt werden, sonst laufen deren Anfragen ins Leere.

Muss ich JWT Auth nutzen, wenn der aufrufende Dienst das nicht anbietet?

Nein, die Authentifizierungsmethode richtet sich immer danach, was der aufrufende Dienst tatsächlich unterstützt. Bietet ein Dienst nur einen einfachen API-Key an, passt Header Auth besser als JWT Auth, das ein signiertes Token voraussetzt.