HMAC
HMAC is a way to prove a message came from someone holding a shared secret, and that nobody changed it on the way. A hash function is combined with the secret in a defined order to produce a short tag sent alongside the message. The receiver computes the same tag and compares. It is the mechanism behind almost every webhook signature you will meet.
At a glance
- Category
- Security
- Full name
- Keyed-hash message authentication code
- Needs
- A hash function and a secret both sides hold
- Proves
- Authenticity and integrity — not confidentiality
- Compare with
- A constant-time comparison, never a plain equality check
- Specified in
- RFC 2104
How it works
The sender takes the exact bytes it is about to transmit and computes a hash over them mixed with the shared secret, in the specific two-pass construction the specification defines. The resulting tag travels in a header. The receiver repeats the computation over the bytes it actually received and compares its own tag with the one that arrived. Any change to the payload, and any attempt to forge a tag without the secret, produces a mismatch, because the hash cannot be recomputed without the key.
Why it matters
A webhook endpoint is a public URL, so anything on the internet can post to it. Without a signature the only thing distinguishing a real event from an invented one is that the attacker has to guess the shape of your JSON, which is not a security control. HMAC turns the endpoint into something only the service can write to. The details matter as much as the idea: hash the raw bytes rather than a re-serialised object, and compare in constant time.
Example
A service computes a tag over the timestamp and the raw request body using the endpoint's secret, and sends it in a header. Your handler reads the body as bytes before any JSON parsing, recomputes the tag with the same secret, and compares the two with a constant-time function. It also refuses anything whose timestamp is far from now, so a request captured earlier cannot be replayed at you later.
Common mistakes
- 01Verifying against a re-serialised body, so a harmless difference in key order or spacing breaks every signature.
- 02Comparing tags with an ordinary equality operator, which leaks timing information an attacker can use.
- 03Checking the signature but not the timestamp, which leaves a captured request replayable indefinitely.
- 04Keeping the signing secret in the same place as the code that verifies it, so a repository leak hands an attacker both halves at once.
In Rasket
Webhook deliveries are signed with a per-endpoint secret, and a published helper package verifies the signature and the timestamp for you. Webhooks
Related terms
Frequently asked questions
Does HMAC encrypt the payload?
No. It proves who sent the bytes and that they were not altered, but the bytes themselves are unchanged. Confidentiality comes from sending over HTTPS, not from the signature.
Why does the raw body matter so much?
Because the tag is computed over exact bytes. Parsing JSON and serialising it again can change whitespace, key order or number formatting, and any of those produces a different hash.
What hash function should be used?
A modern one from the SHA-2 family is the normal choice, and it is what most webhook signing schemes specify. The construction in RFC 2104 is defined for any suitable hash function.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.