Eine Webhook-URL funktioniert wie ein Türspalt ohne Schloss: Wer die Adresse kennt, kommt herein. Niemand meldet sich an, niemand fragt nach dem Ausweis.
Vorstellen lässt sich eine Hinterwerkstattür, die ein zustellender Bote regelmäßig nutzt. Der Bote kennt die Tür, schiebt Pakete durch und geht wieder. Ein Fremder, der die Adresse der Tür einmal gesehen hat, kann dieselbe Tür genauso benutzen. Er wirft dann keine echten Pakete hinein, sondern ausgedachte.
Die Tür ist die Webhook-URL, die Adresse, unter der ein Workflow auf Anfragen wartet. Ein Webhook ist ein HTTP-Aufruf, meist POST mit JSON-Body, den ein System bei einem Ereignis an genau diese URL sendet. Der Riegel fehlt: Ohne weitere Prüfung genügt die Kenntnis der Adresse, um eine Anfrage abzusetzen, ganz ohne Anmeldung. HTTPS verschlüsselt zwar die Verbindung auf dem Weg, sagt aber nichts darüber, wer gesendet hat.
Konkret sieht das so aus: In n8n richtet man einen Webhook-Trigger über den Webhook Node ein, der eine URL bereitstellt. Wer diese URL kennt, kann mit einem einfachen HTTP-POST-Programm eine ausgedachte Bestellung senden und den Workflow starten, als wäre das Ereignis echt.
Das Bild hat eine Grenze: Eine Tür kann man abschließen, eine bloße URL nicht. Das Schloss ist eine Signaturprüfung mit einem gemeinsamen Geheimnis, etwa per HMAC-SHA256; nur wer das Geheimnis kennt, erzeugt eine gültige Signatur.
Deshalb: Die Webhook-URL wie ein Passwort behandeln, nur über HTTPS erreichbar machen und bei Kündigung oder Verdacht auf Bekanntwerden neu vergeben. Nicht in Repositorien, Screenshots, Dokumentationen oder Logs veröffentlichen.
Wer die Adresse kennt, kann senden. Die URL schützt niemanden, sie benennt nur die Tür.
📌 HTTPS · Vertraulichkeit · Signaturprüfung
📚 Automatisierung von Grund auf · Tag 3 von 30
#Webhooks #n8n #Automatisierung #datenschutz
Vorstellen lässt sich eine Hinterwerkstattür, die ein zustellender Bote regelmäßig nutzt. Der Bote kennt die Tür, schiebt Pakete durch und geht wieder. Ein Fremder, der die Adresse der Tür einmal gesehen hat, kann dieselbe Tür genauso benutzen. Er wirft dann keine echten Pakete hinein, sondern ausgedachte.
Die Tür ist die Webhook-URL, die Adresse, unter der ein Workflow auf Anfragen wartet. Ein Webhook ist ein HTTP-Aufruf, meist POST mit JSON-Body, den ein System bei einem Ereignis an genau diese URL sendet. Der Riegel fehlt: Ohne weitere Prüfung genügt die Kenntnis der Adresse, um eine Anfrage abzusetzen, ganz ohne Anmeldung. HTTPS verschlüsselt zwar die Verbindung auf dem Weg, sagt aber nichts darüber, wer gesendet hat.
Konkret sieht das so aus: In n8n richtet man einen Webhook-Trigger über den Webhook Node ein, der eine URL bereitstellt. Wer diese URL kennt, kann mit einem einfachen HTTP-POST-Programm eine ausgedachte Bestellung senden und den Workflow starten, als wäre das Ereignis echt.
Das Bild hat eine Grenze: Eine Tür kann man abschließen, eine bloße URL nicht. Das Schloss ist eine Signaturprüfung mit einem gemeinsamen Geheimnis, etwa per HMAC-SHA256; nur wer das Geheimnis kennt, erzeugt eine gültige Signatur.
Deshalb: Die Webhook-URL wie ein Passwort behandeln, nur über HTTPS erreichbar machen und bei Kündigung oder Verdacht auf Bekanntwerden neu vergeben. Nicht in Repositorien, Screenshots, Dokumentationen oder Logs veröffentlichen.
Wer die Adresse kennt, kann senden. Die URL schützt niemanden, sie benennt nur die Tür.
📌 HTTPS · Vertraulichkeit · Signaturprüfung
📚 Automatisierung von Grund auf · Tag 3 von 30
#Webhooks #n8n #Automatisierung #datenschutz
2 Tage vor
