What is webhook security? Protecting endpoints with best practices

Webhooks power event-driven architectures from CI/CD pipelines to payment systems, but these HTTP callbacks require exposing permanent endpoints that create security risks.

Read on to learn more about webhook security and eight security measures, including signatures, TLS, authentication, and replay protection. These techniques help technical teams secure webhooks while maintaining performance.

What is webhook security?

Webhooks are HTTP callbacks for real-time communication between services. Unlike polling APIs repeatedly, providers send HTTP POST requests with JSON payloads directly to your endpoint when events occur.

Webhook security protects these callbacks from attacks. Since webhooks receive incoming HTTP requests, attackers can potentially trigger unauthorized actions, steal data, or access internal systems through forged or modified requests.

Unlike polling, where you control outbound requests, webhooks require exposing a public endpoint and trusting incoming requests. This means you need to validate messages, use encryption, and defend against attacks.

Both providers and consumers share security responsibilities. Providers should sign payloads and use HTTPS, while consumers need to verify signatures, authenticate senders, and secure endpoints. Webflow's CMS and App Platform use webhooks for content publishing and form submissions, making these security measures critical for production systems.

Why webhook security matters

Webhooks expose always-on HTTP endpoints accessible to any external service or attacker. When compromised, these endpoints can lead to consequences, including data breaches, service disruptions, unauthorized transactions, and compliance violations, as webhook-triggered workflows often execute automatically without human verification.

Common attacks against webhook endpoints include:

1. A Server-Side Request Forgery (SSRF) allows attackers to manipulate callback URLs so your systems make requests to internal resources. This can leak sensitive data when your webhook service trusts user-provided URLs.
2. Replay attacks capture legitimate HTTP requests and repeatedly send them to trigger the same action multiple times. For example, an order.completed webhook could charge customers repeatedly if replayed.
3. Traffic interception attacks target webhooks sent over plain HTTP or poorly configured TLS. Attackers can read or modify this traffic before it reaches your application.
4. Denial-of-service attacks (DDoS) flood your endpoint with fake requests, overwhelming your system and blocking legitimate events.

Understanding these threats will help you implement the defense strategies outlined in the following section.

8 webhook security best practices

The following practical security measures help protect your webhook endpoints from common attacks while maintaining performance. Each technique addresses a specific vulnerability and can be implemented independently or as part of a comprehensive security strategy.

1. Sign every webhook (HMAC or JWT)

Signatures prevent webhook tampering by validating message authenticity and integrity. Most providers, including Webflow, use HMAC, where the provider hashes the payload with a shared secret and sends this hash in a header like X-Signature. You compute the same hash and compare values to detect altered messages.

Most providers use HMAC signatures. Some may issue JWTs for additional context, but this is less common.. It can include context data and supports signing with either shared secrets (HS256) or asymmetric keys (RS256).

// verify-hmac.js
import crypto from 'node:crypto';

export function verifyHmac({ rawBody, header, secret }) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(rawBody, 'utf8')
    .digest('hex');

  // constant-time compare to avoid timing attacks
  return crypto.timingSafeEqual(
    Buffer.from(expected, 'hex'),
    Buffer.from(header, 'hex')
  );
}

Store secrets in a secure vault rather than source control and rotate them regularly. With proper signature verification in place, forged requests fail before reaching application logic.

2. Always use HTTPS (TLS or mTLS)

HTTPS prevents data exposure by encrypting webhook traffic against eavesdropping and tampering. Plain HTTP transmits payloads in cleartext, making them vulnerable to interception attacks. Standard HTTPS protects traffic through server certificate validation and encryption, which all webhook providers, including Webflow, require.

For higher security, mutual TLS (mTLS) requires certificates from both parties, blocking unauthorized senders before request processing. While effective, it adds certificate management overhead.

Always automate certificate renewal, implement fingerprint pinning where possible, and reject all webhook traffic sent over unencrypted channels.

3. Require authentication for the receiving endpoint

Authentication verifies webhook sender identity to prevent unauthorized access even when HTTPS is used. Common methods include Basic auth with Authorization: Basic base64(user:pass) headers, bearer tokens with Authorization: Bearer <token>, or API keys in headers like X-Api-Key. HMAC signatures also function as authentication.

Always rotate credentials regularly and store them securely outside code.

// express-middleware.js
export function authenticate(req, res, next) {
  const token = req.get('Authorization')?.replace('Bearer ', '');
  if (token !== process.env.WEBFLOW_WEBHOOK_TOKEN) {
    return res.status(401).end();
  }
  next();
}

Layer authentication with signature verification for stronger security. Webflow allows HMAC signature configuration that requires attackers to know your secret to forge requests.

4. Add timestamps (and nonces) to stop replay attacks

Timestamps narrow the replay window, but use nonces or idempotency keys to fully prevent duplicate processing. Adding a UNIX timestamp to your signature lets you reject messages older than a few minutes, which generally blocks replays.

const FIVE_MIN = 5 * 60; // seconds
function isFresh(ts) {
  const diff = Math.abs(Date.now() / 1000 - Number(ts));
  return diff < FIVE_MIN;
}

For stronger protection, implement nonces as unique identifiers stored in a fast database. When a previously seen nonce appears again, drop the request. This approach also provides idempotency during legitimate retry attempts.

5. Use certificate pinning or IP allow-listing

Certificate pinning and IP allow-listing protect webhooks by verifying sender identity at the connection level. Certificate pinning stores expected certificate fingerprints and rejects connections that don't match, blocking attacks even when certificates appear valid. IP allow-listing filters traffic by approved source addresses, providing simpler implementation but less reliability with cloud providers that use dynamic IP ranges.

Where feasible, combine IP allow-listing with certificate validation. Full certificate pinning is difficult at scale and best reserved for controlled environments. Always automate certificate updates and set alerts for validation failures to prevent unexpected downtime.

6. Avoid sending sensitive data in webhooks

Minimize sensitive data in webhook payloads to prevent leaks and reduce security risks. Don't include unnecessary information in webhook messages. Instead of sending personal or payment data directly, use minimal identifiers like this:

/

{
  "event": "order.created",
  "orderId": "abc123"
}

Your backend should fetch complete records through secure API calls with proper authentication. When some sensitive data needs to be included, encrypt it before signing and only decrypt it after verification. This approach simplifies compliance with privacy regulations and limits potential damage from exposure.