Webhook Abuse in Express with Bearer Tokens

Webhook abuse in Express when Bearer Tokens are involved typically arises from insufficient validation of the token and the webhook origin. A common pattern is an Express route that accepts POST events and expects a Bearer Token in the Authorization header to authenticate the sender. If the route only checks for the presence of a token and does not validate it against a known source or scope, an attacker can replay captured requests or inject arbitrary tokens to trigger unintended actions.

Consider an endpoint that processes payment notifications or resource updates. If the handler trusts the Bearer Token without verifying its issuer, audience, or scope, an attacker who knows or guesses a valid token can invoke the webhook programmatically. This can lead to unauthorized operations, such as changing user permissions or initiating transfers. Because the endpoint is designed to be called externally, it may skip typical session-based checks, increasing the risk when tokens are not tightly bound to the webhook context.

Another vector involves token leakage through logs, error messages, or insecure storage. If an Express app logs full Authorization headers without redaction, tokens may be exposed. Additionally, if the same token is used across multiple integrations (e.g., shared between webhook consumers and internal services), compromise of one channel can affect others. Attackers may also exploit misconfigured CORS or missing origin checks to send crafted requests that appear to come from trusted sources, especially when the Bearer Token is the primary gatekeeper.

The combination of webhook URLs being publicly discoverable (e.g., stored in client-side code or configuration files) and Bearer Tokens being passed in headers can create a scenario where enumeration or brute-force attempts are feasible. If rate limiting is not applied to the webhook endpoint, an attacker can submit many token values rapidly, testing for acceptance. This is particularly dangerous when token entropy is low or when tokens are reused across environments, such as staging and production, which can be discovered through information leakage.

To illustrate a vulnerable Express route using Bearer Tokens, consider the following example where token validation is incomplete:

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

app.post('/webhook', (req, res) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    return res.status(401).send('Missing token');
  }

  // Vulnerable: only checks token presence, not validity
  if (token === 'my-secret-token') {
    // Process webhook logic
    res.status(200).send('OK');
  } else {
    res.status(403).send('Invalid token');
  }
});

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

In this snippet, the token is compared directly to a hardcoded value. While this prevents completely unauthenticated access, it does not protect against token reuse, replay, or exposure. A more robust approach involves verifying the token against an authorization server, checking scopes, and ensuring the webhook request includes additional context such as an event ID and timestamp to prevent replays.

Remediation focuses on validating Bearer Tokens rigorously and binding them to the webhook context. Instead of comparing tokens directly to a static string, integrate with an identity provider or introspection endpoint. Use libraries that support JWT verification if tokens are JWTs, and always validate issuer, audience, and expiration. Include additional request metadata such as a signature or HMAC to ensure integrity.

Below is a revised Express route that demonstrates a more secure pattern using JWT verification and replay protection through a simple timestamp and nonce check:

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

const PUBLIC_KEY = `-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
-----END PUBLIC KEY-----`;

const seenNonces = new Set();

function verifyToken(token) {
  try {
    const decoded = jwt.verify(token, PUBLIC_KEY, { algorithms: ['RS256'] });
    return decoded;
  } catch (err) {
    return null;
  }
}

app.post('/webhook', (req, res) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    return res.status(401).send('Missing token');
  }

  const payload = verifyToken(token);
  if (!payload) {
    return res.status(403).send('Invalid token');
  }

  // Replay protection: ensure nonce and timestamp are present and fresh
  const nonce = req.headers['x-nonce'];
  const timestamp = req.headers['x-timestamp'];
  if (!nonce || !timestamp) {
    return res.status(400).send('Missing security headers');
  }

  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - parseInt(timestamp, 10)) > 300) {
    return res.status(400).send('Request expired');
  }

  if (seenNonces.has(nonce)) {
    return res.status(409).send('Duplicate request');
  }
  seenNonces.add(nonce);

  // Process webhook securely
  res.status(200).send('OK');
});

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

This example verifies the JWT using a public key, ensuring the token was issued by a trusted authority. It also requires nonce and timestamp headers to mitigate replay attacks within a short window. For production, store nonces in a fast, expiring cache rather than a Set to support distributed systems and avoid memory growth.

When using shared secrets or opaque tokens, prefer token introspection via a central authorization service. Here is an alternative approach that calls an introspection endpoint before processing the webhook:

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

app.post('/webhook', async (req, res) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    return res.status(401).send('Missing token');
  }

  try {
    const response = await axios.post('https://auth.example.com/introspect', null, {
      params: { token },
      auth: { username: 'webhook-consumer', password: 'client-secret' }
    });

    if (!response.data.active) {
      return res.status(403).send('Token not active');
    }

    // Optionally validate additional claims such as scope or custom metadata
    if (!response.data.scope || !response.data.scope.includes('webhook:process')) {
      return res.status(403).send('Insufficient scope');
    }

    // Process webhook
    res.status(200).send('OK');
  } catch (error) {
    res.status(502).send('Introspection failed');
  }
});

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

This approach moves token validation to the authorization server, reducing the risk of accepting forged tokens. Combined with transport layer protections and monitoring for anomalous webhook volumes, these measures significantly reduce webhook abuse risk when Bearer Tokens are used.