Denial Of Service in Express with Hmac Signatures

HMAC signatures are designed to verify integrity and authenticity by using a shared secret to sign requests. In Express, developers often sign payloads or query parameters and then verify the signature before processing business logic. If signature verification is performed after expensive operations or if the algorithm or key management is weak, the endpoint becomes susceptible to denial of service. An attacker can send many requests with malformed or heavy payloads that require full parsing and verification, consuming CPU and memory without producing a valid signature match, effectively making the service unavailable.

Another vector is the use of weak or predictable secrets. If the HMAC secret is leaked or brute-forced, an attacker can craft many valid-looking requests that trigger resource-intensive processing, such as database lookups or file operations, before the signature is ultimately rejected. Inefficient implementation, such as recomputing the HMAC on large request bodies multiple times or performing signature checks inside loops, amplifies CPU usage. This is especially dangerous when the signature scheme relies on algorithms that are more expensive to verify than to generate, allowing an attacker to force the server into costly cryptographic work with each request.

Additionally, improper handling of missing or malformed signature headers can lead to denial of service. If the verification logic throws unhandled exceptions or enters deep recursion when encountering unexpected formats, the event loop can be blocked or the process can crash. Without proper validation early in the middleware stack, requests that lack or misuse HMAC signatures can consume disproportionate resources. Because the checks occur after payload parsing and before business logic, inefficient placement of the HMAC verification step can turn an otherwise lightweight endpoint into a denial-of-service vector.

To mitigate denial-of-service risks, enforce early validation of HMAC signatures before any heavy processing. Validate the presence and format of the signature header first, and reject malformed requests immediately. Use a fast, constant-time comparison for signature verification to avoid timing attacks and ensure predictable CPU usage. Limit the maximum size of request bodies and reject oversized payloads before parsing.

const crypto = require('crypto');
const express = require('express');
const app = express();

// Limit body size to mitigate resource exhaustion
app.use(express.json({ limit: '10kb' }));

function verifyHmac(req, res, next) {
  const signature = req.get('X-Hub-Signature-256');
  if (!signature || !signature.startsWith('sha256=')) {
    return res.status(400).json({ error: 'Missing or invalid signature header' });
  }
  const hash = signature.split('=')[1];
  const expected = crypto.createHmac('sha256', process.env.HMAC_SECRET)
                         .update(JSON.stringify(req.body))
                         .digest('hex');
  // Use timing-safe compare to avoid DoS via forced branching
  const isValid = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(hash));
  if (!isValid) {
    return res.status(401).json({ error: 'Invalid signature' });
  }
  next();
}

app.post('/webhook', verifyHmac, (req, res) => {
  // Business logic only after verification
  res.json({ received: true });
});

app.listen(3000);

For better defense, offload signature verification to a lightweight reverse proxy or API gateway when possible, and enforce rate limits per client to reduce the impact of bursts of malicious requests. Monitor request sizes and signature failure rates to detect scanning or abuse.