make.com Security & Secrets-Management: Connections, Webhooks, IP-Whitelisting (2026)

Warum Security in Automatisierungs-Plattformen unterschätzt wird

Make.com ist mächtig – und genau das macht es zu einem attraktiven Ziel. Ein einziges schlecht konfiguriertes Szenario kann:

• Kundendaten an falsche Empfänger verschicken
• API-Keys von Dritt-Tools leaken
• Als Einfallstor für Webhook-Spam und DoS dienen
• DSGVO-Verstöße auslösen, die deutlich teurer sind als jedes Make-Abo

Die gute Nachricht: Make liefert 2026 alle Bausteine für ein professionelles Security-Setup. Du musst sie nur richtig einsetzen.

Die vier Säulen sicherer make.com Setups

1. Connections: Least-Privilege als Default

Jede Connection ist eine potenzielle Angriffsfläche. Behandle sie wie produktive Service-Accounts:

• Dedizierte Service-User statt persönlicher Accounts (kein "tills-google-account" in Produktion)
• Scopes minimieren: Wenn du nur Kalender liest, brauchst du keinen Drive-Schreibzugriff
• OAuth statt API-Key, wo möglich – Tokens lassen sich revoken, ohne den Account zu sperren
• Connections benennen: prod-monday-readonly, staging-shopify-orders, nicht monday 2
• Rotations-Termin im Kalender: Alle 90 Tage Tokens rotieren

Make's Team Workspaces (2026) erlauben Connection-Sharing pro Workspace mit Rollen – nutze das, statt Connections in Personal-Accounts zu lagern.

2. Webhooks: Niemals offen ins Netz

Custom Webhook URLs in Make sind standardmäßig öffentlich erreichbar. Wer die URL kennt, kann das Szenario triggern. Drei Härtungs-Schichten:

a) Shared Secret im Header oder Payload

Konfiguriere im Webhook ein Pflicht-Feld X-Webhook-Secret und prüfe es im ersten Modul mit einem Filter. Bundle ohne korrekten Secret werden verworfen, Operations bleiben minimal.

// Filter-Bedingung
{{1.headers.`x-webhook-secret`}} = {{$env.WEBHOOK_SECRET}}

b) IP-Whitelisting auf der Quell-Seite

Wenn die Quelle (CRM, Shop, internes System) statische Egress-IPs hat:

• IPs als Filter-Bedingung im ersten Modul prüfen
• Oder: Vorgeschalteter Reverse Proxy (Cloudflare, AWS API Gateway), der nur Make-IPs durchlässt

Make selbst publiziert Egress-IP-Bereiche pro Region – diese kannst du auf der Empfänger-Seite als Allowlist hinterlegen.

c) Rate Limiting & Replay Protection

• Timestamp-Check: Webhook-Payload muss timestamp enthalten, älter als 5 Min → reject
• Idempotency-Key: Pro Bundle ein eindeutiger Key, in Data Store nachschlagen, Doppel-Trigger verwerfen

3. Secrets: Niemals hardcoden

Der häufigste Fail in Make-Szenarien: API-Keys, Tokens, Passwörter direkt in HTTP-Modulen oder Tools-Variablen. Drei bessere Wege:

Ansatz	Wann nutzen	Sicherheits-Niveau
Native Connections	Wann immer ein App-Modul existiert	⭐⭐⭐⭐
Make Data Store mit Secret-Records	HTTP-Module, Custom APIs	⭐⭐⭐
External Vault (HashiCorp, AWS Secrets Manager, 1Password)	Hochsensible Daten, Compliance	⭐⭐⭐⭐⭐

Anti-Pattern: Secrets in Szenario-Notes, Modul-Beschreibungen oder Test-Daten. Diese landen in Blueprints und Exports.

Pattern: Vault-Lookup beim Szenario-Start

Erstes Modul ist ein HTTP-Call an deinen Vault (z. B. AWS Secrets Manager via OIDC). Die zurückgegebenen Secrets bleiben im Bundle und werden für die Session genutzt. Vorteile:

• Keine Secrets im Make-Tenant gespeichert
• Rotation passiert vault-seitig, ohne Szenario-Änderung
• Audit-Log liegt im Vault, nicht in Make

4. Audit-Logging & Access Control

Make protokolliert standardmäßig wer wann welches Szenario geändert hat – aber nur in den höheren Plänen vollständig. Ergänze:

• Access Control: Edit-Rechte auf Senior-Builder beschränken, View-Rechte für den Rest
• Approval-Flow für produktive Szenarien (z. B. via Pull-Request-ähnlichem Review im Team)
• Externe Audit-Logs: Webhook auf "Scenario Updated"-Event in dein SIEM (Datadog, Splunk, Better Stack) spiegeln

Wie du Logs strukturiert nach extern bringst, zeigt unser Monitoring & Observability Guide.

DSGVO-Spezifika für DACH-Teams

• Region wählen: Make bietet EU-Hosting (Frankfurt). Bei Onboarding eu1.make.com wählen, sonst landen Daten in US-Rechenzentren.
• Auftragsverarbeitungs-Vertrag (AVV): Make stellt einen Standard-AVV bereit, der für die meisten Setups ausreicht – im Admin-Portal abrufbar.
• Daten-Minimierung: Filter so früh wie möglich setzen. Wenn du nur die E-Mail brauchst, übertrage nicht den ganzen User-Datensatz.
• Logs-Retention: Make speichert Execution-Logs bis zu 90 Tage. Personenbezogene Daten in Bundles → Retention auf das Minimum reduzieren.

Security-Checkliste für jedes Produktiv-Szenario

Check	Status
Dedizierte Service-Connection (kein Personal Account)	☐
Scopes auf das Minimum reduziert	☐
Webhook mit Shared Secret abgesichert	☐
IP-Whitelist auf Empfänger-Seite gesetzt	☐
Idempotency- oder Timestamp-Check eingebaut	☐
Keine Secrets in Modul-Beschreibungen / Notes	☐
Sensible Secrets im Vault, nicht im Tenant	☐
Edit-Rechte auf Senior-Builder beschränkt	☐
Daten-Minimierungs-Filter direkt nach Trigger	☐
EU-Region & AVV abgeschlossen	☐
Audit-Log-Webhook ins SIEM aktiv	☐

Anti-Patterns, die du sofort fixen solltest

❌ Webhook-URL im Slack-Kanal teilen – jeder mit Channel-Zugang kann das Szenario triggern.

❌ API-Key in der HTTP-Modul-URL statt im Header – landet in Logs und Browser-History.

❌ Globale Admin-Connection für alle Szenarien – ein kompromittiertes Szenario kompromittiert alles.

❌ Test-Daten mit echten Kundeninformationen – Bundles bleiben in Execution History sichtbar.

❌ "Allow all"-Filter, weil's gerade pressiert – kein Szenario geht so live, ohne dass es zu einem Incident wird.

Fazit

Make-Security ist kein Produkt, das du einkaufst – es ist eine Disziplin in jedem Szenario. Wer Connections, Webhooks und Secrets von Anfang an sauber baut, spart sich Incident-Reports, DSGVO-Bußgelder und Notfall-Rotationen mitten in der Nacht.

Für Teams mit komplexen Compliance-Anforderungen (Finance, Health, Public) bieten wir Security-Reviews bestehender Make-Setups inklusive Pen-Test der Webhook-Endpoints.

→ Security-Review buchen

Weiterführend

• Make Automatisierungs-Guide
• Error Handling & Retry-Strategien
• Monitoring & Observability für make.com
• Make Module Migrator: monday.com V1 zu V2