Okay, I have to get this off my chest because I’ve been deep in the sandbox this week testing a new lead routing flow between a custom app and HubSpot, and I’m genuinely baffled.
It feels like every time I evaluate a “low-code” runtime or a new “serverless function” platform for handling inbound webhooks—think places like Vercel Edge Functions, Cloudflare Workers, even some native automation builders—their documentation treats security as step 10 in a 5-step process. The first example is always just a basic `if (req.body.secret === 'mysecret')` check, if that! It’s like they assume the webhook endpoint URL itself is a secret, which we all know is security through obscurity at best.
I’ve been testing a few, and here’s what I consistently see missing or buried:
* **No built-in, easy pattern for signature verification** (like HubSpot’s X-HubSpot-Signature or Shopify’s HMAC). You have to manually implement it every single time, and the crypto libraries aren’t always straightforward in those environments.
* **IP allow-listing is often a nightmare** because the runtime’s own IP range isn’t documented or is dynamic. How am I supposed to lock down the endpoint to, say, only Salesforce’s known IPs if my function platform shares IPs with random customer traffic?
* **Timeout configurations** that are too short for proper validation logic before acknowledging receipt. You end up just accepting the payload to avoid a retry, then processing it async, which is fine, but that pattern isn’t in the “getting started” guide.
* **Almost zero guidance on idempotency** for handling retries. If the same webhook fires twice, my function runs twice. I have to build my own dedupe layer every. single. project.
It just seems like these platforms are optimized for “hello world” speed and getting a function live in 30 seconds, but the moment you need to handle a real, sensitive webhook—with customer data from a CRM or a payment event—you’re left scrambling to bolt on security that should be part of the fabric.
Am I being too critical? Has anyone else found a runtime or platform that actually gets this right and provides these safeguards as easy, configurable options rather than DIY homework? I’d love to compare notes.
— Emma
If it's not measurable, it's not marketing.
Preach. The IP allow-listing rant is spot on. I tried to lock down a Pipedrive webhook endpoint on a Cloudflare Worker last year. Their "outbound IP" documentation was a single, outdated support article that basically said "it's dynamic, good luck." Had to build a separate proxy just to get a static IP, which defeats the whole point of using the serverless function.
And don't get me started on the crypto libs in those runtimes. Trying to validate a signature in a Vercel Edge Function felt like performing surgery with mittens on.
been there, migrated that
You've hit on the two major pain points: the IP allow-listing problem and the crypto library issue. On the IP front, the dynamic nature of serverless outbound IPs is a fundamental architectural mismatch for many SaaS vendors that only support static IP allow-listing. I've seen teams implement a "proxy-as-a-service" pattern just to get a stable IP, which adds latency, cost, and a new single point of failure, negating many serverless benefits.
Regarding the crypto libs, the mittens analogy is perfect. The problem is that many of these runtimes use a restricted subset of Web Crypto API or have subtly different implementations for Node.js vs. edge. Validating a standard HMAC signature from, say, Stripe or GitHub can become a multi-step debugging session because the provided example code often assumes a Node environment. You end up writing your own byte-array-to-hex-string conversion utilities just to perform a basic verification that should be a one-liner.
—KM