Direct answer
A webhook receiver should authenticate the sender using the provider's documented method and verify integrity over the exact signed material. A request that resembles a real event is not proof of origin.
Identify the signed material
Read the sender's signature specification: providers differ in encoding, signed fields, timestamp handling and header names. Identify the receiving endpoint, key owner and authorized test event. Some schemes sign the raw body; parsing and reserializing JSON before verification can change its bytes.
Reference: OWASP Webhook Security Cheat Sheet.
Compare valid and tampered events
Send a genuine provider test event and record the expected accepted outcome. In a test environment, repeat the request with one harmless body field changed while retaining the old signature, then without the signature. Confirm those variants cannot trigger the protected action.
- Use the vendor's test tooling and a disposable event.
- Do not include production secrets or customer payloads in evidence.
- Verify the actual processing result, not just the HTTP response.
Check secret rotation
Where the protocol supports a planned overlap, confirm deliveries signed by both designated test secrets are accepted during the window and that the retired secret fails afterward. Keep credentials in an approved secret store; compare signatures using the provider's recommended safe method.
Separate authenticity from business logic
A valid sender can still send malformed data or an event the application should not process. Validate event type, size and business context, and authorize any object changes independently. Record failed verification without logging the signature secret or sensitive payload.
Assessment limits
Signature verification alone does not prevent replay or duplicate processing. Each provider has different signed fields and retry behavior; verify the implementation against its own current specification.
Frequently asked questions
Is an IP allowlist enough to authenticate a webhook?
Use it as an additional layer where appropriate; shared or changing provider addresses do not replace the provider's authentication mechanism.
Why preserve the raw request body?
Many providers sign exact bytes. Changing whitespace or key ordering before verifying can invalidate a genuine signature or make the implementation inconsistent.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.
This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.