Your no-code webhooks are public endpoints (and you probably don't know it)

Your no-code webhooks are public endpoints. You probably didn't know.

In nine out of ten Make, n8n, or Zapier accounts we audit, the same pattern shows up. Webhooks arrive. Workflows execute. Money moves. Nobody on the receiving side ever verifies that the request came from who it claims.

The setup looks healthy. It runs without errors. It is also wide open to anyone on the public internet who stumbles across the URL.

The webhook URL is the credential

When you create a webhook trigger in Make or n8n, the platform hands you a URL like `https://hook.eu1.make.com/abc123xyz`. From that moment, possession of the URL equals authorization to trigger the workflow.

URLs travel. They live in Stripe dashboards, in Slack threads from two years ago, in screenshots inside abandoned Notion pages, in old support tickets, in `.env` files of forgotten staging environments. Whoever finds one of those can trigger your workflow. There is no second authentication step by default.

Worst case behind that URL: a workflow that issues invoices, posts to Salesforce, grants access, or calls an OpenAI endpoint that bills you per token.

Real providers sign their requests for a reason

Stripe, GitHub, Shopify, Slack, Twilio, HubSpot. All of them sign webhook payloads with a shared secret. They compute an HMAC over the body, attach it as a header, and expect the receiving side to verify it before acting on the data.

The header name varies: `Stripe-Signature`, `X-Hub-Signature-256`, `X-Shopify-Hmac-SHA256`. The mechanism is identical. Without verification on the receiver side, the header is decoration.

A signed but unverified webhook is functionally identical to an unsigned one. The cryptography on the sender side is wasted unless you actually check it.

What we keep finding in audits

In the past twelve months, we have reviewed more than 40 production no-code accounts. The recurring findings:

• A Stripe webhook syncing payment events into the accounting system. No signature check. Anyone with the URL could inject fake payments into bookkeeping.
• A GitHub webhook triggering deployments via n8n. No signature check. A leaked URL would let anyone simulate a push event and deploy arbitrary payloads.
• A Typeform submission firing an OpenAI call per message and emailing the result back. No validation. The client was paying mid four figures per month for inference and had no way to trace which invocations were legitimate.

None of these clients had a documented attack. That proves only that nobody looked. The logs were not designed to surface unauthorized invocations.

Why this gap exists in no-code

We hear three reasons in client conversations.

First, the platforms downplay it. Make's default webhook trigger does not surface signature handling in the basic UI. n8n has the building blocks but no opinionated default. Zapier handles a subset of providers automatically through its official integrations and leaves the rest to you.

Second, things appear to work. The webhook arrives, the workflow runs, no alarms go off. Security failures are invisible until they are not.

Third, the implementation feels intimidating. HMAC, SHA-256, Base64 decoding, header parsing. For a team that chose no-code precisely to avoid this kind of plumbing, it reads like infrastructure work they wanted to skip.

Verification in practice

The work involved is modest. In n8n: a Crypto node in HMAC mode, an If node, a compare step. Fifteen minutes the first time, copy and paste for every subsequent workflow.

In Make: a bit more involved because you need to capture the raw body, not the parsed JSON. The platform offers the tools, but you have to know they exist. Once you build it the first time, you wrap it in a reusable subscenario and the next ten integrations cost ten minutes each.

We ship every client engagement with a small library of these subworkflows, one per common provider. The cost per integration is negligible. The protection it provides is the difference between a workflow you control and an endpoint anyone on the internet can hit.

What we tell clients to do

Three concrete steps for any company running production webhooks today.

Inventory. List every inbound webhook. Who sends it. What it triggers. Whether the request is verified. This list does not exist in most accounts we see. Building it takes half a day and is the prerequisite for every meaningful conversation about exposure.

Prioritize. Any webhook that writes to a system handling money, customer data, or external actions gets signature verification. Read-only flows that log to an internal sheet can wait.

Negotiate. If a partner sends webhooks without signatures, push for a shared secret in a header or, at minimum, an unguessable token in the URL. Both options are weaker than HMAC. Both are stronger than the silence most setups currently rely on.

We treat webhook endpoints like public API surfaces in every consulting engagement. Because that is exactly what they are. The setups that have not had incidents have avoided them because nobody found the URL. Yet.

That is not a security model. That is a coin toss.

If you don't know which of your active webhooks verify signatures, our free Automations Check is the place to start. We go through your list together and decide which endpoints to lock down first.