The double standard of webhook security and API security

This seems deeply confused.<p>When you are making an API request, you&#x27;ve validated the certificate of the system you&#x27;re making the request to and in the process doing so over a secure connection. You&#x27;ve usually authenticated yourself, also over a secure connection, and are including some sort of token validating that authentication which provides your authorization as well.<p>When you are accepting a call in your web hook, you need to ensure that the call came from the authenticated source which the signature provides. The web hook caller connects using the same certificate validation and secure connection infrastructure. They won&#x27;t connect if your certificate doesn&#x27;t validate or they can&#x27;t establish a secure connection. The signature is their mechanism of authenticating with your API except that they are the authority of their identity.<p>That last bit is where the the contradiction falls away, the webhook implementer is retaining authentication authority and infrastructure (whether you call them or they are calling you) rather than asking the client to provide an authentication system for them to validate themselves with.<p>[edit: there&#x27;s an additional factor. If you move authentication to the web hook implementer you lose control of what authentication mechanisms are in use. Having to implement everyone&#x27;s authentication systems would be a nightmare full of contradictions. You also open yourself up to having to follow client processes, attend meetings, and otherwise not be able to automate the process of setting up a webhook.]

Ooh this is a favorite pet peeve of mine. HMAC is the better solution IMO but API Keys are so much easier for your customers to use:<p>- API Keys are much, _much_ easier to use from the command line. CURL with HMAC is finicky at best and turns a one-liner into a big script<p>- Maintaining N client libraries for your REST API is hard and means you&#x27;ll likely deprioritize non-mainstream languages. If a customer needs to write their own library to interact with your service, needing to incorporate their own HMAC adds even more friction.<p>- Tools have gotten much better in recent years- it is much easier to configure a logger to ignore sensitive fields now compared to ~10 years ago

One of the patterns I often reach for when working with webhooks is &quot;never trust them to do anything other than set a should-refresh flag on a related object, or upsert a stub identity for a new related object, for asynchronous reprocessing which will then call out to get the latest relevant state.&quot;<p>Assume that things will come out of order, may be repeated, may come in giant rushes if there&#x27;s a misconfiguration or traffic spike, and may have payload details change at any time in hard-to-replicate ways (unless you&#x27;re archiving every payload and associating it with errors). If you make the &quot;signal&quot; be nothing more than an idempotent flag-set, then many of these challenges go away. And even if someone tries to send unauthenticated requests, the worst they can do is change the order in which your objects are reprocessed. Signature verification is important, but it becomes less critical.

I&#x27;ve always had a small bit of simmering resentment when something wants me to set up a webhook into my system, and provides no way of authorizing the hook.<p>Stripe and Twilio do it best, with signatures that verify they&#x27;re the ones sending the hook, but I&#x27;d even settle for http basic auth. So many of them seem to say &quot;hey here&#x27;s the IP addresses well be sending raw posts to your provided URL with, btw these IPs can change at any time without warning.

This entire article seems poorly written, or rather not have thought through the real security requirements. It seems to be intended as an ad piece, but honestly for me it does the exact opposite, tells me I shouldn&#x27;t be using this company for my APIs.<p>&gt; However, webhooks aren’t so different from any other API request. They’re just an HTTP request from one server to another. So why not use an API key just like any other API request to check who sent the request?<p>Because it&#x27;s still you requesting the event to happen, not the origin of the webhook. It makes no sense for the webhook to use normal API key mechanisms that are designed to control access to an API; the API is accessing you. (To be clear, of course it wouldn&#x27;t use the <i>same</i> API key as inbound, that&#x27;s a ridiculous suggestion. I&#x27;m saying the mechanics of API keys don&#x27;t match this use.)<p>The real issue is that the webhook receiver should authenticate itself to the sender of the webhook, and the only widespread way that&#x27;s currently happening is HTTPS certificate checks. As the article kinda points out for the other direction, that&#x27;s kind of an auxiliary function and it&#x27;s a bit questionable to rely on that. One way to do this properly would be to add another layer of encryption, which only the intended webhook receiver is given the keys for, e.g. the entire payload could be put into an encrypted PCKS#7 container. This would aid against attackers that get a hold of the webhook target in some external manner, e.g. hijacking DNS (which is enough to issue new valid certificates these days, with ACME).<p>&gt; Signing requests does give extra security points, but why do we collectively place higher security requirements on webhook requests than API requests?<p>And now the article gets really confused, because it&#x27;s misidentifying the problem. The point of signing a request that already makes use of an API key would be integrity protection, except <i>that</i> is indeed a function HTTPS can reasonably be relied on for in this scenario. Would a more &quot;complex&quot; key reduce the risk of lieaking it in log files or somesuch? Sure, but that&#x27;s an aspect of API keys frequently being &quot;loggable&quot; strings. X509 keys as multi-line PEM text might show up less frequently in leaks due to their formatting, but that&#x27;s not a statement about where and how to use them cryptographically.

&gt; return actual == expected<p>Usually you&#x27;d want to use a method which prevent timing attacks for this check. Even php provides hash_equals for this usecase.

The difference is that vendors have a good reason to widely distribute a public key. They are sending messages via webhooks to many customers, all of whom need to authenticate the same vendor. Publishing a public key solves this. The vendor could even bake it into open source software that customers download.<p>A vendor’s customers aren’t distributing software. They’re only sending messages via API calls to the vendor. This is many-to-one instead of one-to-many. The key distribution problem is solved differently: each customer saves a different API key to a file. There’s no key distribution problem that would be made easier by publishing a public key.<p>(That is, on the sending side. The receiving side is handled via TLS.)<p>It’s a web request either way, but this isn’t peer-to-peer communication, so the symmetry is broken.

I&#x27;ve asked this question: <a href="https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;273569&#x2F;why-are-hmac-signatures-frequently-used-for-webhook-authorization-but-not-other" rel="nofollow">https:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;273569&#x2F;why-are-...</a><p>I never got a satisfactory answer, but I think the article is correct.<p>Signed requests is hard for clients, and there are more API clients (consumers) than webhook clients (services).

request signing is strictly better... except that developers complain when you try to implement anything harder than an api bearer token (see recent threads on google gemini &#x2F; vertex apis).

I get that it&#x27;s just supposed to be illustrative, but the &quot;verify_request()&quot; function presented is cryptographically unsound because the == comparison is not constant-time.

You need to check origin and authenticity of a webhook, whereas your API key is there to verify that you are the right person. In an API call, origin is already checked by HTTPS.

The APIs that require signed requests come with ready made libraries for every major programming language, hiding that stuff from the user.<p>And with signed webhook requests, the recipient can simply ignore the signature if they deem the additional security it grants unnecessary.

It makes me sad that TLS client certificates are not known and in turn mostly neglected.

API keys are symmetrical, so every client needs a unique one. Singing allows the server to have only one certificate for all clients (webhook receivers). More convenient.

The post is about how webhook requests are usually signed and api responses are not.<p>For me it seems clear that the reason for this different approach is that api requests are already authenticated. Signing them would yield little additional security. Diminishing returns like the debate over long lived (manually refreshed) api keys versus short lived access tokens with long lived refresh tokens - or, annoyingly, single use refresh tokens that you have to keep track of along with the access token.<p>Webhooks are unauthenticated post requests that anyone could send if they know the receiving url, so they inherently need sender verification.

if you want to authenticate the caller, its better to use mTLS (or TLS with client cert). Client certificates and https is basically SSH, but for the web.

OAuth 1.0a requires API requests to be signed.

I know that survey panels like HMAC. They pay their respondents (a bit of) money for each survey they complete. And of course there are bots for that, and the simplest strategy is to immediately call the survey panel&#x27;s end point that registers a response as complete (triggering payment). That can be stopped by making the surveyor signing the link upon true completion. Just adding a key isn&#x27;t going to cut it.