Webhook Security Best Practices: HMAC, Replay Attacks & Encryption

Webhooks are the quiet infrastructure behind most modern integrations

API endpoint security
automated webhook signing
cryptographic signing webhooks
developer API security
encrypting webhooks at rest
enterprise webhook security
HMAC signature verification
how to secure webhooks
implementing webhook HMAC
InstaWebhook encryption
InstaWebhook security
outgoing HMAC signing
payload verification tutorial
preventing man in the middle attacks webhooks
prevent webhook replay attacks
production webhook security
safe webhook ingestion
secure callback URLs
secure event driven architecture
secure public APIs
secure webhook architecture
securing public endpoints
securing third party webhooks
webhook authentication
webhook best practices
webhook data integrity
webhook data protection
webhook encryption mechanisms
webhook header verification
webhook HMAC verification
webhook infrastructure security
webhook message integrity
webhook origin verification
webhook payload encryption
webhook payload security
webhook retry security
webhook security
webhook security architecture
webhook security best practices
webhook security compliance
webhook security guide
webhook security tools
webhook security vulnerabilities
webhooks HTTPS enforcement
webhook signing secrets
webhook tamper proofing
webhook threat modeling
webhook timestamp verification
webhook token authentication
webhook validation
Webhook-Security-Best-Practices-HMAC-Replay-Attacks-Encryption
Webhook Security Best Practices: HMAC Verification, Replay Protection, and Payload Encryption
Webhooks are the quiet infrastructure behind most modern integrations. A payment clears in Stripe, a commit lands on GitHub, a deal moves stages in your CRM — and a second later, an HTTP POST lands on your server carrying that news. It's a simple pattern, but it comes with an uncomfortable trade-off: to receive a webhook, you have to expose an endpoint to the open internet, and that endpoint has to trust data sent by a stranger.

This guide covers what actually goes wrong with webhook endpoints, how the industry has converged on fixing it, and working code you can adapt — checked against current provider documentation rather than assumptions.

What You're Actually Defending Against
Forged requests. A webhook is just a POST request. If your handler doesn't verify where it came from, anyone who finds the URL can send a fake "payment succeeded" or "subscription upgraded" event. This is the single most common webhook flaw in the wild.

Replay attacks. Even a legitimate, correctly-signed request can be captured and resent. If your server can't tell a duplicate from the original, it will happily re-run the action — crediting a wallet twice, re-provisioning an account, re-sending a shipment.

Interception and tampering. Without transport encryption, anything riding over the wire — API keys, PII, financial data — can be read or altered in transit.

Timing attacks on signature checks. Naive string comparison (===) exits as soon as it hits a mismatched byte, and that timing difference is measurable. Given enough attempts, an attacker can reconstruct a valid signature byte-by-byte.

Server-side request forgery (SSRF) — and this cuts both ways. Most write-ups only talk about the inbound side (verifying requests you receive). If you also send webhooks to URLs your customers configure, your outbound delivery worker is effectively an HTTP client that takes instructions from untrusted tenants. A malicious or compromised customer can point their webhook URL at your internal network — cloud metadata endpoints like 169.254.169.254, internal admin panels, or databases — and use DNS rebinding to get past a one-time validation check. OWASP's guidance on this is explicit: URL validation at registration time is not sufficient on its own, because DNS can change between the check and the actual request. Production systems re-resolve and re-validate the IP at delivery time, block private/loopback address ranges, disable automatic redirect-following (or re-validate after every hop), and run the delivery workers in an isolated network segment with no route to internal services.

Layer One: Transport and Network Controls
HTTPS is non-negotiable. It's the baseline that stops passive eavesdropping and in-transit tampering. No provider worth using will let you register a plain http:// endpoint for anything sensitive.

IP allowlisting is a helpful filter, not a security boundary. Stripe, for instance, does publish the IP ranges it sends webhooks from, and you can use that at your firewall. But IP-based trust is fragile: ranges get shared across cloud tenants, addresses get reassigned, and spoofing at the network layer is possible in some environments. Treat it as one more filter to reduce noise, never as your only authentication mechanism.

Mutual TLS (mTLS) is worth the operational overhead in zero-trust or regulated environments — both sides present certificates, so the connection itself authenticates the peer before any HTTP logic runs.

None of these tell you the payload wasn't forged or replayed. That's what signing is for.

Layer Two: HMAC Signature Verification
The dominant pattern across the industry is HMAC-SHA256: the sender hashes the request using a secret only the two of you know, and puts the result in a header. You recompute the same hash on your end and compare.

A few real examples, since the exact header names and formats differ by provider:

GitHub sends X-Hub-Signature-256: sha256=, computed as HMAC-SHA256 over the raw payload with your configured webhook secret. GitHub explicitly deprecates the older SHA-1-based X-Hub-Signature header in favor of this one.
Stripe sends a Stripe-Signature header formatted as t=,v1=, where the signature is HMAC-SHA256 over the string {timestamp}.{raw_body} — the timestamp is baked into the signed content, not just appended alongside it.
Standard Webhooks — an open specification now used by companies including OpenAI, Anthropic, Google Gemini, Twilio, PagerDuty, and Supabase — defines webhook-id, webhook-timestamp, and webhook-signature headers, again signing the concatenation of ID, timestamp, and raw body with HMAC-SHA256, with the header carrying a version prefix (v1,) so schemes can evolve without breaking old consumers.
The two mistakes that break almost every homegrown implementation:

Verifying against a re-parsed body instead of the raw bytes. If your framework parses JSON before your verification code runs, whitespace and key ordering can shift, and the hash will never match. Capture the raw request buffer before any JSON middleware touches it.
Comparing signatures with ===. This leaks timing information. Use a constant-time comparison function instead.
Here's a working Node.js/Express example that reflects current best practice — raw body capture, HMAC-SHA256, and constant-time comparison:

Code example
Copy code
const express = require('express');
const crypto = require('crypto');
const app = express();

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;

// Capture the raw body BEFORE any JSON parsing happens
app.use(express.json({
verify: (req, res, buf) => {
req.rawBody = buf;
}
}));

app.post('/webhook', (req, res) => {
const signatureHeader = req.headers['x-provider-signature'];
if (!signatureHeader) {
return res.status(401).send('Missing signature header');
}

try {
const expected = crypto
.createHmac('sha256', WEBHOOK_SECRET)
.update(req.rawBody)
.digest('hex');

const expectedBuf = Buffer.from(expected, 'utf8');
const receivedBuf = Buffer.from(signatureHeader, 'utf8');

const isValid =
  expectedBuf.length === receivedBuf.length &&
  crypto.timingSafeEqual(expectedBuf, receivedBuf);

if (!isValid) {
  return res.status(401).send('Invalid signature');
}

// Signature verified — safe to process req.body
res.status(200).send('Webhook received');

} catch (err) {
console.error('Webhook verification failed:', err);
res.status(500).send('Internal Server Error');
}
});

app.listen(3000);
In production, prefer your provider's official SDK over hand-rolled HMAC where one exists (Stripe's SDKs, the standardwebhooks libraries, etc.) — they already handle multi-value signature headers, key rotation windows, and edge cases that are easy to get subtly wrong by hand.

Layer Three: Stopping Replay Attacks
A valid signature only proves the payload wasn't altered — it says nothing about whether you're seeing it for the first time. That's why every major implementation folds a timestamp into the signed content itself, so an attacker can't just swap in a fresher timestamp without invalidating the whole signature.

The tolerance window that's become a de facto standard: 5 minutes. Stripe's official libraries default to rejecting anything more than 300 seconds off from server time; Svix's libraries do the same; it shows up repeatedly across OWASP-adjacent guidance as the recommended ceiling. It's not an arbitrary number from one vendor — it's the number the ecosystem has converged on, tight enough to close the replay window, loose enough to tolerate normal clock drift and network latency. Keep your server clock synced via NTP, and never set the tolerance to zero — that disables the recency check entirely rather than tightening it.

Code example
Copy code
const MAX_TOLERANCE_SECONDS = 5 * 60;

app.post('/webhook-secure', (req, res) => {
const signatureHeader = req.headers['x-provider-signature'];
const timestampHeader = req.headers['x-timestamp'];

if (!signatureHeader || !timestampHeader) {
return res.status(401).send('Missing authentication headers');
}

const now = Math.floor(Date.now() / 1000);
const webhookTime = parseInt(timestampHeader, 10);

if (Math.abs(now - webhookTime) > MAX_TOLERANCE_SECONDS) {
return res.status(401).send('Timestamp outside tolerance window');
}

const signedPayload = ${timestampHeader}.${req.rawBody.toString('utf8')};
const expected = crypto.createHmac('sha256', WEBHOOK_SECRET)
.update(signedPayload)
.digest('hex');

const expectedBuf = Buffer.from(expected, 'utf8');
const receivedBuf = Buffer.from(signatureHeader, 'utf8');

if (expectedBuf.length !== receivedBuf.length || !crypto.timingSafeEqual(expectedBuf, receivedBuf)) {
return res.status(401).send('Invalid signature');
}

res.status(200).send('Validated');
});
Idempotency handles the legitimate-retry case. Timestamp checks stop attackers; they don't stop your provider from retrying a delivery that timed out or got a non-2xx response — which every major provider will do. Every well-designed webhook payload includes a unique event ID (webhook-id in the Standard Webhooks spec, event.id in Stripe). Store processed IDs — Redis with a TTL slightly longer than your retry window is the common pattern — and if you see one you've already handled, return 200 immediately without re-running your business logic.

Layer Four: Payload Privacy — In Transit and At Rest
HTTPS protects the payload while it's crossing the network. It does nothing once your load balancer terminates TLS and the request starts moving through your internal services in plaintext. This is the point where sensitive data most often leaks — accidentally logged into Datadog or Splunk, written unencrypted into a retry queue, or stored in an event-sourcing table without protection. That's a real compliance problem under SOC 2, HIPAA, and PCI-DSS if the payload contains cardholder data, health data, or other PII.

Practical measures:

Scrub before you log. Don't dump raw webhook bodies into general-purpose logging pipelines. Redact or hash sensitive fields first.
Encrypt at rest. Anything durable — retry queues, audit logs, event stores — should use AES-256 encryption at rest, same as any other data store holding sensitive information.
Consider payload-level encryption (JWE) for genuinely sensitive data. Beyond transport security, some high-sensitivity integrations encrypt the payload itself with JSON Web Encryption before signing: the sender encrypts with your public key, signs the encrypted blob with HMAC, and you verify the signature before decrypting with your private key. This is a heavier pattern reserved for cases where the payload itself (not just the connection) needs confidentiality guarantees independent of your infrastructure.
Layer Five: Secrets and Rotation
An airtight HMAC scheme is only as good as the secret behind it.

Store secrets in environment variables or a dedicated secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) — never in source control.
Rotate on a schedule, and do it with an overlap window rather than a hard cutover. This isn't theoretical: it's how real systems do it. Stripe's dashboard lets you roll a signing secret with a configurable expiration delay of up to 24 hours, during which both the old and new secrets are valid and Stripe signs with both. The Standard Webhooks spec formalizes the same idea — during rotation, the sender signs with both keys and sends both signatures, space-delimited, in the signature header, and your verifier accepts either until the old key is retired. Build your verification logic to accept a list of valid secrets, not just one, from the start.
The Direction the Industry Is Actually Moving
Worth calling out explicitly: webhook security used to be reinvented from scratch by every provider, with slightly different header names, payload formats, and signing conventions. That's been changing. Standard Webhooks, an open specification originally driven by Svix, defines a consistent set of headers (webhook-id, webhook-timestamp, webhook-signature), a consistent signing scheme (HMAC-SHA256 over ID + timestamp + raw body, with support for key rotation and even asymmetric Ed25519 signatures), and has been adopted by a notable list of companies — including OpenAI, Anthropic, Google Gemini, Kong, Twilio, PagerDuty, Etsy, and Supabase, among others. If you're designing a new outbound webhook system, building to this spec rather than inventing your own header format saves your integrators from relearning signature verification for every provider they add — and it means you inherit a scheme that's already been reviewed by a wider community than just your own team.

A Working Checklist
Reject any webhook not delivered over HTTPS
Verify HMAC-SHA256 signatures against the raw, unparsed request body
Use a constant-time comparison function — never ===
Validate a signed timestamp with roughly a 5-minute tolerance window
Deduplicate by event ID to absorb legitimate provider retries
If you send webhooks to customer-supplied URLs, re-resolve DNS and block private/loopback IPs at delivery time, not just at registration
Disable automatic redirect-following on outbound delivery requests, or re-validate the destination after each hop
Keep webhook secrets in a secret manager, never hardcoded
Rotate secrets on a schedule using an overlapping validity window
Encrypt sensitive payloads at rest; scrub them before they hit general logging systems
Further Reading
Stripe: Verify webhook signatures
GitHub: Validating webhook deliveries
Standard Webhooks specification
OWASP: Server-Side Request Forgery Prevention Cheat Sheet
OWASP: Webhook Security Guidelines (draft cheat sheet)