webhook-sentry VS svix-webhooks

>Domains that resolve to private IPs: attacker could set up foo.com which resolves to a private IP

There's a clever extension to this attack; a naive way to mitigate it is to do a DNS resolution first to verify it's not a private IP and then do the actual request. An attacker can simply return a public IP on the first DNS resolution (with a 0 TTY) and then return a private IP on the second. This is called a "TOCTOU" (time-of-check time-of-use) vulnerability. I've written about this and other security best practices on my blog here - https://www.ameyalokare.com/technology/webhooks/2021/05/03/s...

I've also built an egress proxy that prevents such attacks here - https://github.com/juggernaut/webhook-sentry

Same caveat applies, use at your own risk :-)

That's exactly why we built Svix[1]. Building webhooks services, even with amazing tools like FastAPI, Celery and Redis is still a big pain. So we just built a product to solve it.

Hatchet looks cool nonetheless. Queues are a pain for many other use-cases too.

1: https://www.svix.com

Obviously Deno have vested interest it (and so do I as the founder of Svix[1]), but my take is that webhooks are great, though there are alternatives that could be better or complementary depending on the situation.

At Svix we also support running JS instead of sending webhooks (using Deno!), and it is very useful, but there are many limitations with this approach, and in general oftentimes people just want the data passed to their systems and deal with it there. Not write a bit of JS to do something ad-hoc.

So in short, like always with software engineering: "it depends" and there are tradeoffs to each approach.

1: https://www.svix.com

Svix - Webhooks as a Service. Send up to 50,000 messages/month for free.

We opted for a more manual approach, we have a ctx!() macro[1] we use for wrapping errors we want to enrich thay we use like this[2]: ctx!(some_fallible_fund(foo))?

I wodner if anyone is doing anything better? The nice thing is that we have relevant fields in our error type, so we get a full backtrace out if it.

1: https://github.com/svix/svix-webhooks/blob/main/server/svix-...

2: https://github.com/svix/svix-webhooks/blob/main/server/svix-...

This is what we do at Svix: https://docs.svix.com/receiving/source-ips

I've seen other companies (e.g. Stripe) also offer it via JSON, but I personally think it's not that important to provide it in a machine readable format if you don't plan on changing it; which you shouldn't as it'll break integrations. You should only add new IPs that can only be allocated to new customers.

P.S, if you'd like to start sending webhooks, you should probably check out Svix: https://www.svix.com

If I understand you, you just want some queue system, like kafka.But if you want a whole app who handle all your webhooks usage you can see : https://github.com/svix/svix-webhooks/

Might want to look into Svix and HostedHooks

Repository on Github: https://github.com/svix/svix-webhooks