Great website! Love the completeness.
It would be interesting to add information about idempotency in your replay prevention page.

Some web hook will send you an ID that is guaranteed to be unique on replay. Very useful to avoid doing work twice. This is too often forgotten by the consumer.

Source: https://www.reddit.com/r/programming/comments/x38ixt/webhooksfyi_a_site_about_webhook_best_practices/

https://github.com/zapier/resthooks

REST Hooks prescribes a set of APIs for consumers to manage their own webhook subscriptions.

I am dusting off https://www.reddit.com/r/webhooks/ and was wondering if y'all would be up for adding some info on community resources?

There is also https://groups.google.com/g/webhooks

http://webhooks.fyi shows nothing. Only https://webhooks.fyi works.

To fix:

Add the same record we have in the DNS for webhooks.fyi to [www.webhooks.fyi](http://www.webhooks.fyi/) . Github takes care of the rest.

This is a proposal to add CloudEvents under the "Standardisation Efforts" section.

CloudEvents is a CNCF incubating project.

https://cloudevents.io

CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.

It provides specification on message modelling and event payload design multiple protocols from AQMP to HTTP and HTTP Webhooks.

This could also cover a fair bit on #33

I'll be happy to contribute to this one.

Source: https://www.reddit.com/r/programming/comments/x38ixt/webhooksfyi_a_site_about_webhook_best_practices/

Webhooks can be a little bit of a hassle when developing locally. That is probably why ngrok is pushing them.
What I am missing from this overview, is the data less webhook. Sending a webhook without any authentication and without any payload (except maybe a single id), but only to notify new info can be retrieved.
This will really simplify the security procedures and also mean that data will only flow in one direction.

Badges: Webhooks.fyi:

• listed

• verified

• profile completeness

• highlighted

• upvoted

https://openid.net/2021/08/24/shared-signals-an-open-standard-for-webhooks/

Source: https://www.reddit.com/r/programming/comments/x38ixt/webhooksfyi_a_site_about_webhook_best_practices/

Fixes:

Webhooks leverage mTLS the same way protocols like HTTPS, SQL, and SSH

• SQL is not a network protocol
• SSH doesn't and can't use mTLS, as it not based on TLS, but on The Secure Shell (SSH) Transport Layer Protocol.
• And of course webhooks leverage mTLS is the exact same way HTTPS does. HTTPS is HTTP sent through a TLS, and mTLS is a part/feature of TLS.

However, mTLS is often difficult to configure

• Change it to "when compared against other methods like HMAC and Basic Auth"

Missed Pros

• Revocation of trust on either side of the connection
• You don't need to implement it, it's just hidden behind a flag and some configuration. Generally, if you understand PKI, there is no risk involved in an mTLS "implementation".

Classification

All in all, I can't agree with the "Very High" complexity rating, for sure the "Assymetric Keys" approach is much more difficult to implement, as it just seems to be somewhat like mTLS implemented at the application layer, and mTLS's biggest strength is that you don't need to implement it yourself, it is already provided by your TLS/HTTPS library.

This website was posted on Hacker News, and there was an excellent comment posted about attack vectors - particularly timeout attacks and private IP attacks. I'd love learn more about these attacks in the Security section of this site, focusing on how to allow users to configure their webhook URLs.

https://news.ycombinator.com/item?id=32518208
Posted by cuu508 on 2022-08-19

There are some interesting attack vectors to be aware of if you run a service where users can define webhooks, and your service will will call the user-defined webhooks to notify about certain system events. In my case, a monitoring service which can send notifications by calling user-defined webhook.

• Timeouts: the user can set up a webhook receiver that takes very long to generate a response. Your service must be able to deal with that.
• Timeouts (slowloris): the webhook target could be sending back one byte at a time, with 1 second pauses inbetween. If you are using, say, the "requests" python library for making HTTP requests, the "timeout" parameter will not help here
• Private IPs and reserved IPs: you probably don't want users defining webhooks to http://127.0.0.1:/ and probing your internal network. Remember about private IPv6 ranges too
• Domains that resolve to private IPs: attacker could set up foo.com which resolves to a private IP. It is not enough to just validate webhook URLs when users set them up.
• HTTP redirects to private IPs. If your HTTP client library follows HTTP redirects, the attacker can set up a webhook endpoint that redirects to a private IP. Again, it is not enough to validate the user-supplied URL.
• Excessive HTTP redirects. The attacker can set up a redirect loop - make sure this does not circumvent your timeout setting.

Comparing Stripe's HMAC steps around timestamp , I would expect the HMAC snippet's digest to include a reference to the message's timestamp somehow or is there something I'm missing?

Disclaimer: newbie!

Signing with asymmetric keys is distinct from encryption, but the article conflates them.

https://webhooks.fyi/security/asymmetric-key-encryption

"Asymmetric key encryption" is what you do to make contents secret, like in GPG where you're sending secret messages to some recipient you know holds a private key. With webhook messages the sender holds the private key, not the recipient (as the article correctly mentions), so it's not encryption; it's only signature generation & validation you're talking about. Using the word encryption to mean signing is confusing and non-standard.

Suggest replacing some terms to use the more industry standard terms, and to make the article most consistent, e.g., but not limited to:

• Encryption --> Signing
• Encrypt --> Sign
• Decryption --> Validation
• Decrypt --> Validate or Verify (depending on the context)

Thanks for the overall helpful guide!

It looks like in #3 the Tailwind license document was accidentally imported

https://tailwindui.com/license

https://github.com/ngrok/webhooks.fyi/blob/main/LICENSE.md

I suspect you want to assert your own intentional license for the content on the webhooks.fyi site. The license as it is makes no sense since it's for another product.

According to @ezekg , our build requires adding markdoc manually.

Investigate and confirm:
#73

(my hunch is yarn vs npm)

RSA signing and verifying are significantly more expensive than symmetric encryption (like AES). This can be problematic for high throughput systems. Signing operation can introduce a bottleneck in sender's infra.