Webhook security: Risks and best practices for mitigation

Are webhooks secure?

Webhooks are not inherently secure. A webhook URL is an endpoint on a server that listens for incoming requests from external services. Because endpoints are typically publicly accessible, webhook security depends on the method of implementation and maintenance strategy, as potential vulnerabilities can arise at various stages in the webhook lifecycle. Here are the top security risks to consider when working with webhooks.

Replay attacks

A replay attack occurs when an attacker captures a valid request, usually through compromised endpoints. The actor, effectively impersonating the original sender, then retransmits the captured request to a target system.

Replay attacks are simple to execute because HTTP communication is stateless. The receiving system can't distinguish between the original request and a replayed request, so it processes each request as a new one. For example, if an attacker captures a payment confirmation webhook, they could resend it to trick the system into processing the same transaction multiple times.

Server-side request forgery

In a server-side request forgery (SSRF) attack, malicious actors modify user-defined URLs to redirect the server's requests to unintended and often protected resources, like internal databases and cloud metadata.

Webhook systems are prone to SSRF because their core functionality allows users to specify callback URLs for receiving notifications. This design inherently trusts user input and creates a direct path for attackers to influence server-side requests.

Man-in-the-middle attacks

As the name suggests, a man-in-the-middle (MiTM) attack transpires when a malicious actor intercepts HTTP requests between a webhook sender and receiver. The attacker can then eavesdrop on, modify or even fabricate webhook payloads before forwarding them to the intended recipient.

Webhook MiTM attacks generally exploit unsecured webhook endpoints or intercept webhook traffic over unencrypted connections. Attackers might also compromise the network infrastructure between the webhook sender and receiver or use techniques like DNS spoofing to redirect webhook traffic through their systems and manipulate data in transit.

Distributed denial-of-service attacks

A distributed denial-of-service (DDoS) attack targets a webhook endpoint and overwhelms it with requests from a network of compromised devices, or botnet. The sudden flood of traffic can slow the server or make it entirely unavailable, thus causing the denial of service.

DDoS attacks are a major webhooks security concern because they can significantly disrupt critical business processes. For example, if a webhook synchronizes data between a company's inventory management system and its e-commerce platform, a DDoS attack could disrupt this real-time process, leading to inaccurate stock levels and unfulfilled orders.

5 webhook security best practices

Providers and consumers share the responsibility for creating a secure webhook ecosystem. The following best practices can help mitigate risk from both perspectives.

1. Encrypt data using HTTPS

The fundamental way to secure webhooks is to always configure servers to accept and send requests exclusively over HTTPS connections.

Unlike HTTP, which transmits data in plain text, HTTPS uses Transport Layer Security/Secure Socket Layer protocols to encrypt the payload. Encryption makes webhook messages unreadable. Even if a MiMT attacker intercepts a request, the attacker cannot read or modify the data without proper decryption keys.

2. Avoid transmitting sensitive data using webhooks

Webhooks are effective for real-time event notifications but have limited built-in security features. Instead of webhooks, use secure API calls with strong authentication mechanisms to send confidential information.

One best practice is to send minimal, non-sensitive data like event types or IDs through webhooks and then have the receiving system authenticate API requests to retrieve any necessary sensitive information. This way, webhooks can still provide quick notifications while ensuring that access to sensitive data is along properly secured channels.

3. Authenticate sources and consumers

Because most endpoints are publicly accessible, it's important to verify webhook requests to confirm they come from trusted sources.

To do this, check the originating IP addresses of incoming requests. GitHub provides a list of IP ranges that is useful for setting up an IP allow list on a server. To find the current IP addresses, use GitHub's GET /meta endpoint. Be sure to periodically update the allow list, as these addresses might change.

Consider authenticating consumers so that only authorized users can interact with a webhook service. For example, the mutual authentication strategy requires the client and server to present valid digital certificates during connection.

4. Sign webhooks to verify messages

Malicious actors can modify webhook messages during MiTM attacks. But even encrypted requests can be altered if the attacker manages to compromise the encryption process. Signing webhooks using a hash-based message authentication code (HMAC) can further mitigate this risk.

HMAC is a specific type of message authentication code that uses both a cryptographic hash function and a secret key. In webhook implementations, the webhook provider uses this shared secret key to generate an HMAC signature for each payload before sending. They then place this signature in the request headers.

The webhook consumer uses the received payload and their copy of the secret key to recalculate the HMAC and compare it to the provided signature. If the signatures match, it verifies the payload's integrity and confirms it came from a legitimate provider.

5. Send timestamped messages

Signatures help verify the payload's content but verifying the time of the message can prevent replay attacks.

One common verification method involves adding a message expiration timestamp to the payload before generating the signature. When an attacker tries to change the timestamp, they will invalidate the signature and send out an alert to the attempt.

To strengthen the validation process, implement network time protocol synchronization between the server and the webhook provider. This will ensure that both systems operate on the same precise time reference and establish a reliable window for message validity.

Webhook security isn't a one-stop shop

Remember that webhook security is an ongoing process that requires continuous monitoring. In addition to the recommended best practices for securing webhooks, comprehensive health checks, performance metrics and availability monitoring for webhook endpoints are needed to ensure they remain resilient against security threats.

Twain Taylor is a technical writer, musician and runner. Having started his career at Google in its early days, today, Twain is an accomplished tech influencer. He works closely with startups and journals in the cloud-native space.