Webhook Abuse in Express with Api Keys

Webhook abuse in an Express API that relies solely on API keys occurs when an attacker can trigger or intercept webhook deliveries to inject malicious behavior or bypass intended access controls. API keys are often passed in headers, query parameters, or as part of the webhook payload. If the webhook endpoint does not validate the origin of the request and treats the API key as proof of authorization, an attacker can craft or replay requests that appear to come from a trusted source.

Consider an Express service that registers third-party webhooks and authenticates each incoming call with an X-API-Key header. If the endpoint only checks the presence and correctness of the key without also verifying the sender’s identity through a shared secret or an additional integrity mechanism, an attacker who discovers or guesses the key can POST arbitrary data to the endpoint. This can lead to unintended actions such as triggering resource creation, modifying records, or enumerating behavior based on timing and response differences.

In some configurations, API keys are embedded in URLs as query parameters. If the webhook URL is logged, leaked in error messages, or transmitted over unencrypted channels, an attacker who observes the key can replay signed requests at will. Even when the key is rotated, if there is no additional validation of the webhook payload integrity (for example, via signatures), the system remains vulnerable to injection and replay attacks aligned with the OWASP API Top 10 category of Broken Object Level Authorization (BOLA) and Improper Authentication.

Real-world attack patterns include replaying captured requests to create duplicate resources, changing identifiers in the payload to target other users (a BOLA/IDOR vector), or exploiting rate-limiting gaps to exhaust quotas. Because middleBrick tests unauthenticated attack surfaces and flags issues such as missing integrity checks and weak authentication, it can surface webhook configurations where API keys alone are insufficient. The tool also checks for input validation and data exposure risks, highlighting cases where untrusted webhook data could affect downstream systems.

To illustrate the problem, a minimal Express route that only inspects an API key is shown below. This pattern is risky because it does not validate the webhook origin or the integrity of the payload:

const express = require('express');
const app = express();
app.use(express.json());

const VALID_API_KEY = 'sk_live_abcdef123456';

app.post('/webhook', (req, res) => {
  const apiKey = req.headers['x-api-key'];
  if (!apiKey || apiKey !== VALID_API_KEY) {
    return res.status(401).send('Unauthorized');
  }
  // No signature verification, no replay protection
  const { eventId, data } = req.body;
  // Process event — vulnerable to replay and tampering
  res.status(200).send('ok');
});

app.listen(3000, () => console.log('Server running on port 3000'));

In this example, any party that knows or guesses the API key can send arbitrary JSON to /webhook. Because there is no signature verification, replay protection, or strict validation of the event source, the endpoint is susceptible to webhook abuse aligned with insecure integration practices.

Remediation focuses on strengthening authentication and integrity for webhook requests that use API keys. The most effective approach combines a strong shared secret with signature verification so that even if an API key is exposed, an attacker cannot forge valid requests.

A recommended pattern is to use an HMAC signature in a header, such as X-Signature, computed with a shared secret that is never transmitted alongside the API key. The Express route verifies the signature before processing the payload. This ensures authenticity and integrity and mitigates replay and tampering.

The following example demonstrates a more secure implementation:

const express = require('express');
const crypto = require('crypto');
const app = express();
app.use(express.json());

const VALID_API_KEY = 'sk_live_abcdef123456';
const WEBHOOK_SECRET = 'super-secure-shared-secret';

function verifySignature(body, signature) {
  const hmac = crypto.createHmac('sha256', WEBHOOK_SECRET);
  const digest = 'sha256=' + hmac.update(JSON.stringify(body)).digest('hex');
  return digest === signature;
}

app.post('/webhook', (req, res) => {
  const apiKey = req.headers['x-api-key'];
  const signature = req.headers['x-signature'];

  if (!apiKey || apiKey !== VALID_API_KEY) {
    return res.status(401).send('Unauthorized');
  }

  if (!signature || !verifySignature(req.body, signature)) {
    return res.status(400).send('Invalid signature');
  }

  const { eventId, data } = req.body;
  // Process event with verified origin and intact payload
  res.status(200).send('ok');
});

app.listen(3000, () => console.log('Server running on port 3000'));

This approach ensures that the API key identifies the integration, while the HMAC signature proves that the payload was generated by the party holding the shared secret. You can further improve resilience by adding replay protection (for example, rejecting duplicate event IDs within a time window) and enforcing strict content-type checks to avoid parsing ambiguities.

When using the middleBrick CLI (middlebrick scan <url>) or the GitHub Action to add API security checks to your CI/CD pipeline, these patterns help ensure your configuration is flagged as low risk. The Dashboard can be used to track how remediation affects your security scores over time, while the MCP Server allows you to scan APIs directly from your AI coding assistant during development.