Researched guidance: How should a Meta webhook signature be verified against the original request bytes?

Summary

Verify Meta webhook authenticity before parsing or acting on the JSON: preserve the incoming payload representation, compute HMAC-SHA256 with the app secret, and compare it with the digest in X-Hub-Signature-256 after the sha256= prefix.

Candidate action

At the HTTP boundary, capture the request body as received before JSON parsing, Unicode normalization, whitespace changes, or reserialization. Require X-Hub-Signature-256, require the sha256= prefix, and extract the hexadecimal digest after that prefix. Compute HMAC-SHA256 with the Meta app secret over the exact payload representation that Meta signed; Meta's Messenger documentation describes an escaped-Unicode payload and its Node example updates the HMAC with the raw body buffer. Compare the received and calculated digests using a constant-time byte comparison after checking equal length. Reject missing, malformed, or non-matching signatures, and only then parse/dispatch the event. Do not log the app secret or full signed payload.

Applicability

• Inbound Meta webhook POST endpoints, including Graph API and Messenger Platform event notifications that provide X-Hub-Signature-256.
• Frameworks where middleware can expose the raw body buffer or bytes before JSON decoding and normalization.

Key findings

• Meta includes a SHA-256 signature in X-Hub-Signature-256, prefixed with sha256=; validate the digest before treating the payload as genuine. (S1, S2)
• Meta's Messenger documentation says the signed representation uses escaped Unicode with lowercase hexadecimal digits and warns that hashing decoded bytes alone can differ. (S1)
• The documented Node pattern computes HMAC-SHA256 with the app secret over the raw body buffer; a constant-time comparison primitive is suitable for HMAC digests and requires equal-length inputs. (S1, S3)

Known limitations

• Meta's documentation states that signatures use an escaped-Unicode version of the payload, while its example computes over a raw request buffer; exact framework behavior for non-ASCII bodies must be checked against the deployed runtime and payloads.
• Meta's sample comparison is a direct equality check; use the runtime's constant-time comparison primitive as a defense-in-depth implementation choice, with equal-length inputs as required by that primitive.
• This is researched guidance only; no webhook request, signature, or independent reproduction was executed.

Obsolete approaches

• Do not parse JSON and then stringify it to form the verification input; parsing can change bytes, escaping, whitespace, key order, or Unicode representation.
• Do not verify only the parsed fields or rely on the callback verification token as a substitute for X-Hub-Signature-256.

Negative results

• The official Graph API getting-started page confirms the header, sha256= prefix, and matching rule but does not spell out the full body-byte algorithm; the Messenger webhook page supplies the HMAC-SHA256 and escaped-Unicode details.
• No official Meta statement was found that defines one universal raw-body/Unicode handling rule for every Meta webhook product and SDK.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• Documentation supports a proposed verification sequence; it does not establish that a particular framework's body capture or Unicode handling is correct without runtime testing.

What remains unknown

• Whether a specific deployed Meta product, API version, proxy, and framework combination presents the exact escaped-Unicode bytes described by Meta to the verifier.
• Whether any product-specific webhook documentation adds signature rules beyond the Graph API and Messenger guidance reviewed here.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Meta Webhooks for Messenger Platform · official_documentation · accessed 2026-09-22
• S2 Get Started · official_documentation · accessed 2026-09-22
• S3 Crypto | Node.js Documentation · official_documentation · accessed 2026-09-22