Webhook-Signaturen in No-Code: die Sicherheitslücke, die niemand schließt

Neun von zehn Make-Konten haben dieselbe offene Tür

Wir schauen uns regelmäßig Automatisierungs-Setups bei Kunden an. In den meisten Konten findet sich derselbe blinde Fleck: Webhooks werden empfangen und verarbeitet, ohne dass irgendwer prüft, ob die Anfrage tatsächlich vom erwarteten Absender stammt.

Das klingt nach einem theoretischen Problem. In der Praxis ist es eines der konkretesten Sicherheitsrisiken in produktiven No-Code-Setups, und es wird fast immer ignoriert.

Was eine Webhook-URL eigentlich ist

Wenn ein Make-Szenario oder ein n8n-Workflow mit einem Webhook beginnt, generiert die Plattform eine URL, etwa `https://hook.eu1.make.com/abc123xyz`. Diese URL hängt jetzt im Setup. Sie steht in der Stripe-Konfiguration, im GitHub-Repository, im Slack-Channel, in dem die Entwickler sie geteilt haben, um über die Integration zu sprechen.

Solche URLs werden über die Zeit kopiert, geteilt, in Screenshots dokumentiert, in alten Tickets zitiert, in vergessenen Notion-Seiten archiviert. Wer eine solche URL hat, kann den Webhook auslösen. Sonst gibt es keine Authentifizierung.

Im günstigsten Fall steht hinter dem Webhook ein lesender Workflow, der einen Datensatz in einem Logfile ablegt. Im weniger günstigen Fall steht dahinter ein Workflow, der Rechnungen erstellt, Geld bewegt, Datensätze im CRM verändert, Berechtigungen erteilt oder eine kostenpflichtige LLM-Anfrage startet.

Warum jeder seriöse Dienst Signaturen mitschickt

Stripe, GitHub, Shopify, Slack, Twilio, HubSpot. Jeder dieser Anbieter signiert seine Webhook-Payloads. Vereinfacht funktioniert das so: Der Anbieter und Sie kennen ein gemeinsames Geheimnis, das in der Anbieterkonsole hinterlegt ist. Mit diesem Geheimnis erzeugt der Anbieter eine kryptografische Signatur über den Inhalt der Nachricht und schickt sie im HTTP-Header mit, typischerweise als `Stripe-Signature`, `X-Hub-Signature-256` oder `X-Shopify-Hmac-SHA256`.

Auf Ihrer Seite prüfen Sie, bevor Sie auf die Daten vertrauen, mit demselben Geheimnis: Stimmt die Signatur überein? Wenn nein, verwerfen. Wenn ja, weitermachen.

Das ist kein Detail. Das ist die einzige Eigenschaft, die einen produktiven Webhook von einem öffentlich erreichbaren Endpunkt unterscheidet, den jeder Mensch im Internet triggern kann, der die URL kennt.

Was wir in Audits regelmäßig finden

In den letzten zwölf Monaten haben wir über 40 No-Code-Setups bei Kunden gesichtet. Wir haben unter anderem gesehen:

• Stripe-Webhooks, die Zahlungen ins Buchhaltungssystem schreiben. Keine Signaturprüfung. Wer die URL kannte, hätte beliebige Zahlungen ins DATEV-System injizieren können.
• GitHub-Webhooks, die Deployment-Skripte in n8n triggern. Keine Signaturprüfung. Eine durchgesickerte URL hätte ausgereicht, um den Build-Server auf Anweisung Fremder loszujagen.
• Typeform-Submits, die eine LLM-Anfrage pro Eingabe starten und das Ergebnis per Mail ausschicken. Keine Validierung. Der Kunde zahlte mittlere vierstellige Beträge pro Monat an OpenAI, ohne dass irgendwer die Auslöser zuordnen konnte.

In keinem dieser Fälle war ein Angriff dokumentiert. Das beweist nicht, dass keiner stattgefunden hat. Es beweist, dass niemand hingeschaut hat. Die Logs waren nicht so gebaut, dass unautorisierte Aufrufe sichtbar geworden wären.

Warum die Lücke in No-Code so verbreitet ist

Wir hören in Kundengesprächen immer wieder dieselben drei Gründe.

Erstens: die Plattformen verschweigen es. Make bietet zwar eigene Header-Funktionen, der Standard-Webhook-Trigger erwähnt Signaturen in der normalen Anleitung aber nicht. Wer nicht weiß, dass es das gibt, sucht auch nicht danach.

Zweitens: es funktioniert ja. Die Webhooks kommen an, die Workflows laufen, niemand beschwert sich. Sicherheit ist kein Feature, das auffällt, wenn es fehlt. Sie fällt erst auf, wenn es zu spät ist.

Drittens: die Implementierung wirkt aufwendig. Man muss HMAC verstehen, Header parsen, Base64 decodieren. Für ein Team, das No-Code gewählt hat, um genau diese Sorte Plumbing zu vermeiden, klingt das nach Infrastruktur-Arbeit, die niemand übernehmen will.

Wie eine Prüfung konkret aussieht

Der Aufwand ist überschaubar. In n8n: ein Crypto-Modul mit HMAC-Modus, eine If-Node, fertig. Die erste Implementierung dauert vielleicht 15 Minuten, jede weitere wird durch Kopieren erledigt.

In Make ist es etwas aufwendiger, weil Sie den Body als Rohdaten lesen müssen, nicht als geparstes JSON. Die Plattform bietet die Werkzeuge, man muss sie aber kennen. Einmal aufgebaut, lässt sich die Logik in ein wiederverwendbares Sub-Szenario auslagern.

Wir liefern in unseren Beratungsmandaten mittlerweile eine kleine Bibliothek solcher Sub-Workflows mit aus, je einer pro gängigem Anbieter. Der Aufwand pro Integration ist gering. Die Schutzwirkung ist der Unterschied zwischen einem kontrollierten Workflow und einem Endpunkt, den jede Person im Netz aufrufen kann.

Was wir Kunden konkret empfehlen

Drei Schritte für jedes Unternehmen, das Webhooks produktiv einsetzt.

Inventarisieren. Listen Sie jeden eingehenden Webhook auf. Wer schickt ihn, was löst er aus, ob eine Signaturprüfung existiert. Diese Liste fehlt in den meisten Konten. Sie zu erstellen dauert etwa einen halben Tag und ist Grundlage jeder ernsthaften Diskussion über Exposition.

Priorisieren. Jeder Webhook, der schreibend in ein System eingreift, das Geld bewegt, Kundendaten verändert oder externe Aktionen auslöst, bekommt eine Signaturprüfung. Lesende Workflows oder solche, die nur in interne Logs schreiben, können warten.

Verhandeln. Wenn ein Partner Webhooks ohne Signatur schickt, drängen Sie auf ein Shared Secret im Header oder zumindest auf einen schwer erratbaren Token in der URL. Beides ist schwächer als HMAC. Beides ist deutlich besser als die Stille, auf die sich die meisten Setups heute verlassen.

Wir behandeln Webhook-Endpunkte in unserer Beratungspraxis wie öffentliche API-Endpunkte, weil sie genau das sind. Die Setups, in denen bisher nichts passiert ist, hatten Glück. Niemand fand die URL. Das ist keine Sicherheitsstrategie, das ist ein Münzwurf.

Wenn Sie nicht wissen, welche Ihrer aktiven Webhooks Signaturen prüfen, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir gehen die Liste gemeinsam durch und priorisieren, welche Endpunkte als erstes abgesichert werden sollten.