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

Why Security in Automation Platforms Gets Underestimated

Make.com is powerful – and that's exactly what makes it an attractive target. A single misconfigured scenario can:

• Send customer data to the wrong recipients
• Leak API keys from third-party tools
• Become an entry point for webhook spam and DoS attacks
• Trigger GDPR violations that cost more than any Make subscription

The good news: Make ships every building block for a professional security setup in 2026. You just need to use them correctly.

The Four Pillars of Secure make.com Setups

1. Connections: Least-Privilege by Default

Every connection is a potential attack surface. Treat them like production service accounts:

• Dedicated service users instead of personal accounts (no "tills-google-account" in production)
• Minimize scopes: If you only read calendars, you don't need Drive write access
• OAuth over API key wherever possible – tokens can be revoked without locking the account
• Name your connections: prod-monday-readonly, staging-shopify-orders, not monday 2
• Rotation reminder in your calendar: rotate tokens every 90 days

Make's Team Workspaces (2026) allow connection sharing per workspace with roles – use that instead of stashing connections in personal accounts.

2. Webhooks: Never Open to the Internet

Custom webhook URLs in Make are publicly reachable by default. Whoever knows the URL can trigger the scenario. Three layers of hardening:

a) Shared Secret in Header or Payload

Configure a required field X-Webhook-Secret on the webhook and check it in the first module with a filter. Bundles without the correct secret are dropped, operations stay minimal.

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

b) IP Whitelisting on the Source Side

If the source (CRM, shop, internal system) has static egress IPs:

• Check IPs as a filter condition in the first module
• Or: upstream reverse proxy (Cloudflare, AWS API Gateway) that only allows Make IPs through

Make publishes egress IP ranges per region – use them as an allowlist on the receiver side.

c) Rate Limiting & Replay Protection

• Timestamp check: webhook payload must include timestamp, older than 5 min → reject
• Idempotency key: unique key per bundle, look it up in a data store, drop duplicate triggers

3. Secrets: Never Hardcode

The most common fail in Make scenarios: API keys, tokens, passwords directly in HTTP modules or tools variables. Three better paths:

Approach	When to use	Security level
Native connections	Whenever an app module exists	⭐⭐⭐⭐
Make Data Store with secret records	HTTP modules, custom APIs	⭐⭐⭐
External vault (HashiCorp, AWS Secrets Manager, 1Password)	Highly sensitive data, compliance	⭐⭐⭐⭐⭐

Anti-pattern: Secrets in scenario notes, module descriptions, or test data. They end up in blueprints and exports.

Pattern: Vault Lookup at Scenario Start

The first module is an HTTP call to your vault (e.g., AWS Secrets Manager via OIDC). The returned secrets stay in the bundle and are used for the session. Benefits:

• No secrets stored in the Make tenant
• Rotation happens vault-side, no scenario change required
• Audit log lives in the vault, not in Make

4. Audit Logging & Access Control

Make logs who changed which scenario when by default – but only in higher tiers fully. Add:

• Access control: Edit rights for senior builders only, view rights for the rest
• Approval flow for production scenarios (e.g., a PR-style review in the team)
• External audit logs: webhook on "Scenario Updated" events into your SIEM (Datadog, Splunk, Better Stack)

For getting logs out in a structured way, see our Monitoring & Observability guide.

GDPR Specifics for European Teams

• Choose your region: Make offers EU hosting (Frankfurt). Pick eu1.make.com during onboarding, otherwise data lands in US data centers.
• Data Processing Agreement (DPA): Make provides a standard DPA that covers most setups – available in the admin portal.
• Data minimization: Filter as early as possible. If you only need the email, don't move the entire user record.
• Log retention: Make stores execution logs for up to 90 days. PII in bundles → reduce retention to the minimum.

Security Checklist for Every Production Scenario

Check	Status
Dedicated service connection (no personal account)	☐
Scopes reduced to the minimum	☐
Webhook secured with shared secret	☐
IP whitelist set on the receiver side	☐
Idempotency or timestamp check in place	☐
No secrets in module descriptions / notes	☐
Sensitive secrets in vault, not in tenant	☐
Edit rights restricted to senior builders	☐
Data minimization filter right after trigger	☐
EU region & DPA in place	☐
Audit log webhook into SIEM active	☐

Anti-Patterns to Fix Immediately

❌ Sharing the webhook URL in a Slack channel – anyone with channel access can trigger the scenario.

❌ API key in the HTTP module URL instead of the header – ends up in logs and browser history.

❌ Global admin connection for all scenarios – one compromised scenario compromises everything.

❌ Test data with real customer information – bundles stay visible in execution history.

❌ "Allow all" filter because of time pressure – no scenario goes live like that without becoming an incident.

Conclusion

Make security isn't a product you buy – it's a discipline applied in every scenario. Teams that build connections, webhooks, and secrets cleanly from the start save themselves incident reports, GDPR fines, and emergency rotations in the middle of the night.

For teams with complex compliance requirements (finance, health, public sector), we offer security reviews of existing Make setups including pen-tests of webhook endpoints.

→ Book a security review

Read more

• Make Automation Guide
• Error Handling & Retry Strategies
• Monitoring & Observability for make.com
• Make Module Migrator: monday.com V1 to V2