Automation security: webhooks, access and API keys under control

A webhook without signature verification will run your automation for anyone who knows its address. Stripe states in its documentation that an attacker can send fake events this way and trigger order fulfilment, grant account access or modify records. Automation security therefore comes down to who may start a workflow, which account it acts under and how long the key it uses to reach other services stays valid. Platforms added new tools for this in 2026. n8n verifies webhook signatures in more trigger nodes, Make sends an email when someone uses your connection, and OpenAI lets you set an expiration date on an API key.

This article builds on our guide to AI business process automation, which covers what is worth automating. If you build workflows in n8n or Make, a basic platform comparison is in our article on automation for small businesses with n8n and Make. If you want your workflows built or reviewed by people who do this daily, see our business process automation service.

Automation security: where a workflow leaks most often

The weakest points of an automation are the webhook address, stored connections to company accounts, API keys for paid services and the account on the platform itself.

An automation workflow in n8n, Make or Zapier holds access to several systems at once. One scenario reads orders from the online shop, writes to invoicing, emails customers and calls an AI model. Whoever takes over the workflow gets into every application it connects. On a website you mainly guard the admin login. In an automation the entry points are scattered across the settings of individual nodes, and often nobody sees them together. If you also run WordPress, our 10-point WordPress security checklist covers that side. Here we deal with the workflows that run outside it.

Entry point	What happens if it is abused	First check
Webhook (an address another service calls)	Anyone with the address sends made-up data and starts the workflow	Signature or secret header verification, list of allowed IP addresses
Connection (credential)	A colleague or another workflow acts under your account	Who owns the connection, who it is shared with, who is notified when it is used
API key for an AI or payment service	Someone else’s calls go to your account and your bill	Expiration date, one key per workflow, usage monitoring
Account on the automation platform	Access to all workflows and stored connections at once	Two-factor authentication, roles based on who does what

Go through the table for every workflow that handles money, personal data or customer emails. Start where you have no answer in the last column.

Webhooks: verify who is calling your automation

A webhook accepts a request from anyone who knows its address, so it has to verify a signature, a secret header or at least the sender’s IP address.

The service sending the webhook attaches a signature calculated from a shared secret and the message content. Stripe uses HMAC with SHA-256 and sends the signature in the Stripe-Signature header. The receiving side calculates the signature again and compares. If it does not match, the request is rejected. In its webhook documentation Stripe adds rules that apply to any custom integration:

• compare signatures in constant time so an attacker cannot guess the signature from how fast the server responds,
• check the message timestamp; Stripe libraries have a default tolerance of 5 minutes and a value of 0 turns the check off completely,
• expect the same event to arrive more than once and log the IDs of events you have already processed,
• change the signing secret periodically and replace it as soon as you suspect a leak.

Webhooks in n8n

n8n 2.21, released on 12 May 2026, added signature verification to several trigger nodes at once, for example for Calendly, MailerLite, Customer.io, Twilio and Acuity Scheduling. A request with a missing or invalid signature is rejected with a 401 response. According to the n8n release notes, however, older webhooks keep running without verification so existing workflows do not break. For some nodes the signing key is only created when the webhook is created again; for Customer.io the key has to be added to the credential. Updating alone therefore does not secure old workflows.

The generic Webhook node used for custom integrations offers, according to the n8n documentation, Basic auth, Header auth, JWT auth or None, plus an optional IP allowlist. A request from any other address is rejected with a 403 error. With None, anyone who knows the address can start the workflow. The test URL is registered when you run Listen for Test Event or Execute workflow in the editor, the production URL only once the workflow is published.

Webhooks in Make

A custom webhook in Make has three protections in its settings. IP restrictions process only requests from the listed addresses. A data structure rejects requests that do not match it with code 400. An optional API key is sent in the x-make-apikey header and Make does not show it again after creation, so store it in a password manager straight away. Make deactivates a webhook on its own once it has not been connected to any scenario for more than 5 days (120 hours).

A webhook without any of these protections works like a public button. Whoever finds its address in an old email, a log or a form’s code can start the workflow with whatever data they invent.

Connections and access: which account your workflow acts under

Every connection in an automation acts under a specific account, so you need to know who owns it, who it is shared with and who finds out when someone uses it.

Since May 2026, when a Zap is turned on or published, Zapier checks that its owner has access to every connection the Zap uses. If a connection is not shared with the owner, the Zap will not turn on and the editor shows the step and the connection that need sharing. Zapier explains this in its announcement on owner access to app connections. Connection sharing is available on the Team and Enterprise plans. A colleague you share a connection with can use it in their own Zaps and also sees the test data.

Since 12 August 2026 Make sends an email the first time another team member adds your key or connection to a scenario. According to the Make help centre these notifications are on by default and the owner can turn them off for each connection separately. Leave them on, otherwise you will not hear about a scenario built on top of your access to invoicing. Team roles in Make distinguish full access (Team Admin), an operator who only activates, deactivates and schedules scenarios (Team Operator), and read-only monitoring (Team Monitoring). Since 12 February 2026 you can enforce two-factor authentication for the whole organisation in Make.

In n8n a colleague can use shared credentials but cannot view or edit their details. According to the n8n documentation, sharing is included in all n8n Cloud plans and in the Business and Enterprise plans for self-hosted installations.

In our view, connections to invoicing, the bank and the online shop should belong to a company service account instead of an employee’s personal account. When someone leaves the company and their account is deleted, workflows built on their connections stop working. For each connection, decide whether it belongs to a person or to the company, and transfer it accordingly.

API keys for AI services: expiry, owner and one key per workflow

An API key for an AI model or a payment service needs an owner, an expiration date and the narrowest possible scope, so a leak affects only one workflow.

Since 10 September 2026 OpenAI lets you set an expiration date when creating a project API key. Administrators can enforce a maximum key lifetime at organisation or project level. Since 15 September 2026, according to the OpenAI API changelog, there are also controls that let the organisation and the project govern key creation. In its production best practices OpenAI advises against putting keys in code or public repositories, recommends exposing them to the application through environment variables or a secret management service, and suggests monitoring their usage on the Usage page.

For automations this leads to a few rules we recommend on every platform:

• one key per workflow or per service, named after the workflow, so you know what to switch off after a leak,
• the key belongs to a project or a company service account, never to an employee’s private account,
• an expiry date with a calendar reminder before it, otherwise the workflow stops on the expiry day,
• the key goes into the platform’s credentials, never into node text, an HTTP header or a note that is exported along with the workflow.

The same logic applies to database keys in apps built with AI tools, which we covered in the article on the Supabase Data API access change. For an old key without an expiry date, create a new one with a validity date, switch the workflow to it and delete the old key.

Self-hosted n8n: what you secure yourself

On your own n8n server you are responsible for the encryption key, updates, the public API and the login method.

On first launch n8n generates a random encryption key that encrypts stored credentials and saves it in the ~/.n8n folder. If you lose this key while moving to a new server or restoring from a backup, you cannot use the stored credentials without it. In queue mode, according to the documentation, the N8N_ENCRYPTION_KEY variable has to be set for all workers. The n8n documentation on securing an installation lists these further steps:

• set up SSL and login through SSO (SAML or OIDC),
• enforce two-factor authentication and run a security audit of the installation,
• periodically replace the key that encrypts credentials,
• disable the public API, block nodes you do not use, enable SSRF protection and redact sensitive data from workflow executions.

You disable the public API with the variables N8N_PUBLIC_API_DISABLED=true and N8N_PUBLIC_API_SWAGGERUI_DISABLED=true if no integration needs it. If nobody is responsible for these steps, the server keeps running in the state of its installation day and every bug n8n has fixed since stays open on it.

Automation security in practice: a review in one afternoon

In our experience, a small company with a handful of workflows can be reviewed in roughly one afternoon if you start with the workflows that handle money and personal data.

At smaller companies we mostly see workflows that started as a quick experiment and kept running. Who built them and which access they use may then be known to nobody in the company. Run the review in this order:

1. List all workflows on all platforms and an owner for each. Switch off a workflow without an owner or assign it to someone.
2. For each webhook, find out whether it verifies a signature, a header or an IP address. Check older n8n trigger nodes separately after updating.
3. Go through the connections: who owns them, who they are shared with and whether any of them runs on a former employee’s personal account.
4. Turn on two-factor authentication for everyone on the platform; in Make you can enforce it for the whole organisation.
5. Keep connection usage notifications in Make switched on and check who receives them.
6. Replace API keys for AI services with new ones that expire, one per workflow, and turn on usage monitoring.
7. For self-hosted n8n, confirm the encryption key backup, the current version and a disabled public API if you do not use it.

How we handle it at Denva: we connect automations through the tools’ official interfaces and keep access to the necessary minimum. We build workflows to be observable, so a critical step alerts you immediately when it fails, and we hand them over documented, so you understand them and are not tied to us.

When you can do it yourself and when to bring us in

You can handle it yourself if:

• you have a few workflows on one platform and know who built them,
• you use the cloud version of n8n, Make or Zapier and do not run your own server,
• your webhooks are called by services for which n8n or Make offers verification directly in the settings.

It is worth bringing us in if:

• the workflows were built by someone who has left the company and nobody knows which connections they use,
• you run self-hosted n8n without an encryption key backup or without regular updates,
• a webhook receives orders, payments or personal data and needs custom signature verification.

Conclusion

If your workflows only send internal notifications, it is enough to turn on two-factor authentication, tidy up connections and go through the list of workflows regularly. If they receive orders, payments or personal data, webhook verification and expiring keys belong among the first tasks, and on your own n8n server so does an encryption key backup. When nobody in the company can say who built which workflow and which account it runs under, we recommend turning to specialists and having the workflows mapped first. If you like, we can go through them with you in a no-obligation consultation.

FAQ

Frequently asked questions.

What is webhook signature verification?

It is a check that the request was sent by the service it claims to come from and that nobody changed it on the way. The sender calculates a signature from a shared secret and the message content, for example HMAC with SHA-256, and sends it in a header. The receiving side calculates it again and rejects the request if they do not match.

Is it enough that nobody knows the webhook address?

No. The address can show up in logs, emails, a workflow export or website code, and then anyone can call it. Add signature verification, a secret header or an IP allowlist, which both n8n and Make offer in the webhook settings.

How often should API keys in automations be changed?

Periodically and always as soon as you suspect a leak, as Stripe recommends for webhook signing secrets. Since 10 September 2026 you can set an expiration date on an OpenAI project key, so the old key stops working after that date and the replacement cannot be postponed indefinitely.

Is the cloud version of n8n more secure than self-hosted?

It depends on who manages the server. With self-hosted n8n you are responsible for updates, SSL, the encryption key backup and disabling the public API if you do not need it. Webhooks, connections and API keys have to be secured in both cases.

Will I find out when someone uses my connection in Make?

Yes, since 12 August 2026 Make sends you an email the first time another team member adds your key or connection to a scenario. The notifications are on by default and the owner can turn them off for each connection separately, which we do not recommend.