Check whether your webhook endpoint trusts whatever posts to it

Reads the source, and on this question what it establishes best is where credential material sits. It reports the shapes it recognises, cloud keys, tokens, private key blocks and an api or secret key assigned a literal value, each with the file and the line, along with any environment file committed to the repository. Git history is read in the same pass, because a secret removed in a later commit is still readable in an earlier one and still works until it is rotated. It matches shapes rather than proving absence, so a clean result here is evidence and not proof.

Builds and runs the application, then posts a body of the wrong shape to the state-changing endpoints it advertises in its own API description. Routes are never guessed, so an application that publishes no API description is not probed this way at all and the control is reported uncovered rather than passed. Where endpoints are probed, any that answers with a success rather than a refusal is named rather than counted in a total, and what a handler returns when it fails is read at the same time, because a stack trace sent to an anonymous caller describes how to attack the thing that produced it.

Tests the deployed application from outside with nothing but the address: transport security, security response headers, and what the running service says about itself. It reaches the front door rather than the handler behind it, so on this page it is context rather than the answer, and every control it cannot reach is reported uncovered rather than assumed.

A signature nobody checked, or checked with a plain comparison

The provider signs each delivery over the exact bytes it sent, using a secret only the two of you hold. Verifying that signature is the only thing that makes the caller trustworthy; without it, the endpoint acts on whatever arrives. Two ways it goes wrong. The handler parses the body first, so the bytes that were signed are gone by the time anything verifies them, and a framework that hands you a parsed object has already lost them. Or the digests are compared with an ordinary equality check, which returns as soon as two bytes differ, and how long that took is a measurement of how much of the guess was right. Compare with a constant-time function.

A valid signed payload stays valid forever

A signature proves the delivery came from the provider. It does not prove it came from the provider just now. Anyone who captures one delivery, out of a log, a proxy, a screenshot in a support thread, holds a payload that verifies for as long as the secret does. Two things fix it and you need both: refuse a delivery whose signed timestamp falls outside a narrow window, and refuse an event id you have already recorded.

The provider will send it twice, on purpose

Retries are the contract, not an error condition. A provider that does not get a timely acknowledgement sends the delivery again, and it may send it again regardless. A handler that credits an account, provisions a seat or sends an invoice on every delivery will eventually do it twice. Claim the event id first and in the same transaction as the work, then treat a repeat as an acknowledgement that changes nothing. This is the one on this page that costs money rather than data.

A webhook proves an event happened, not that the sender may act

The payload names a customer, an order, a subscription. That names a record; it does not establish that whoever sent it is allowed to touch that record, and an identifier that arrived in a request is under the sender's control. Look the record up yourself, check it belongs where the event claims, and act on what you found rather than on what you were handed.

The status code is part of the protocol

Answering 500 because your database blinked is right: the provider retries and the event survives. Answering 500 because the payload was malformed asks the provider to keep retrying something that can never succeed, which is how a queue fills up. Answering 200 to something you failed to process throws the event away, quietly, and nothing anywhere will mention it again. Decide which failures are worth a retry and which are permanent, and make the response say which one it is.

How do I secure a webhook endpoint?

Five things, in this order. Verify the signature over the raw bytes before anything parses them. Reject a delivery whose signed timestamp is outside a narrow window. Record the event id and refuse one you have seen. Look up the record the event names instead of trusting what the payload says about it. Return a status code that tells the provider whether retrying will help. Everything else is detail.

Why is Stripe the example everyone uses?

Because a payment webhook is where the consequence is immediate and the same delivery arriving twice is money rather than a duplicate row. Stripe signs each delivery with a secret from your dashboard, puts a timestamp inside what it signs, and publishes a helper that checks both together. The shape is the same for every provider that signs its deliveries. We do not integrate with Stripe or with any other provider; this page is about the endpoint you wrote.

Is comparing the signature with a normal equality check really a problem?

Yes, and it is the cheapest thing on this page to fix. String equality stops at the first byte that differs, so the time it took is a measurement of how much of the attacker's guess was correct, and enough attempts turn that measurement into the secret. Every language ships a constant-time comparison for exactly this. Use it, and compare the digests rather than the raw secrets.

What does a handler that gets this right look like?

Ours is small, and the shape is the point rather than the product. The PayPal endpoint verifies the delivery with PayPal before it does anything else, and an event it cannot verify is logged and dropped rather than recorded. The event id is claimed only after verification, because recording an unverified id would let anyone reserve a real one and starve the delivery that mattered. The work and the record of the work commit together, so nothing is left half applied. Your handler has to do the same things, in whatever framework it is written in.

Do you test my webhook endpoint by sending it a delivery?

No. We hold no signing secret of yours and cannot produce a delivery your provider would have signed, so nothing here replays traffic at you. What a run does establish is listed above: whether the endpoint accepts a body of the wrong shape, what it leaks when it fails, whether a signing secret is sitting in your source or your history, and whether ownership is enforced on the endpoints that change state.

My webhook works. Is that not enough?

Working and safe are different tests, and only one of them is being run in development. Delete the signature check and your integration still passes end to end, because the only thing posting to the endpoint is the provider. The failures arrive the first time somebody who is not your provider posts to it, or the first time your provider posts the same event twice.