A webhook signature is a coded stamp attached to a webhook message that proves two things: the message really came from the sender it claims, and nobody changed it along the way. Because a webhook is just an HTTP request hitting a URL anyone could discover, the signature is what separates a genuine notification from a forged one.
Here is the idea in plain terms. The sender and your server share a secret key in advance. When the sender fires a webhook, it runs the message and the secret through a one-way hashing function to produce the signature, then sends both. Your server runs the exact same calculation with its own copy of the secret. If the signatures match, the message is trustworthy. If not, you throw it away.
It works like a wax seal on a letter. Only someone with the right stamp can make the mark, and a broken seal tells you the contents were touched. Keeping that shared secret safe is the whole game, which is why it belongs in proper secrets management rather than hard-coded in plain sight.
Two practical details trip people up. First, you have to hash the raw request body exactly as it arrived, byte for byte, because reformatting the JSON first changes the result and every check then fails. Second, many providers add a timestamp to the signed data so an attacker cannot grab a real message and replay it hours later, so your check should reject anything too old.
At TopDevs we verify every incoming webhook signature in the integrations we build, so a client’s automations only ever act on messages we can prove are real.
