Protect Webhooks from replay attacks

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem to solve

GitLab provides the use of an optional secret token to be used with webhooks. The secret token is sent with the webhook request in the X-Gitlab-Token HTTP header. The webhook endpoint can use this token to verify the legitimacy of the request. Similarly, GitHub uses a sha256 hash to be sent in their X-Hub-Signature-256 header.

The receiving endpoint then uses the secret to generate a hash and compares the hash signature to confirm validity.

This works well with the exception of a couple of use cases:

• Where the secret is leaked and can be used by the attacker to spoof webhook calls.
• Replay attacks where the entire URI is replayed with the X-Gitlab-Token HTTP header intact.

While MITM attacks are rare, the increase of Evil Twin attacks, HTTPS Spoofing, and even AI/MCP leakage has increased scrutiny of webhook usage with enterprise customers - especially FinTec and HealthCare verticals.

Proposal

Provide a feature which prevents replay attacks and URI spoofing. The feature could be in the form of an ephemeral JWT token (issued by a secrets management solution in the CI pipeline) or something as simple as a nonce to ensure each session is distinct and impervious to replay attack.

A nonce solution could be combined with this issue incorporating a time stamp into the webhook payload

Another upside to this kind of solution is the secret token is not store in the endpoint hash validation code.

Intended users

• Delaney (Development Team Lead)
• Priyanka (Platform Engineer)
• Sidney (Systems Administrator)
• Ingrid (Infrastructure Operator)
• Amy (Application Security Engineer)
• Alex (Security Operations Engineer)
• Cameron (Compliance Manager)

Does this feature require an audit event?

This feature should not change any existing audit events. It simply adds robustness to an existing GitLab feature.