Brute Force Attack in Express with Bearer Tokens

A brute force attack against an Express API that uses Bearer tokens attempts to discover valid tokens by systematically trying many possible values. Even when tokens are long and random, the absence of rate limiting or lockout mechanisms allows an attacker to make a high volume of requests without being blocked. Since Bearer tokens are typically sent in the Authorization header, the attack surface is limited to endpoints that accept and validate those tokens, but missing protections make enumeration feasible.

In Express, if routes that require a Bearer token do not enforce per-identity or per-client rate limits, an attacker can iterate through token values or user IDs rapidly. Without safeguards, each request is processed independently, and the server reveals timing differences or consistent response statuses that help the attacker infer whether a guessed token is valid. This is especially risky when token validity checks do not use constant-time comparisons, as subtle timing variations can leak information.

The combination of predictable token generation, missing account lockout, and lack of exponential backoff enables attackers to bypass authentication by brute force. For example, an attacker may target endpoints such as /api/users/:userId/profile where the token is expected but not tightly bound to a rate limit. The API may return 200 for a valid token and 401 for an invalid one, providing clear feedback that accelerates automated guessing. Without monitoring or throttling, the unauthenticated attack surface includes these routes, and scans can identify whether rate limiting is absent.

OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) and Broken Authentication are relevant here, because weak controls around token validation enable unauthorized access. A brute force attack can lead to unauthorized data access, privilege escalation if tokens are tied to roles, and compliance violations. MiddleBrick scans include checks for rate limiting and authentication effectiveness, helping to detect whether an Express service is vulnerable to token guessing by identifying missing or insufficient controls.

To secure Express APIs using Bearer tokens, implement rate limiting, token binding, and consistent validation behavior. Use middleware to enforce request thresholds per token or per client IP, and ensure responses do not reveal token validity through timing differences.

Example Express setup with Bearer token validation and rate limiting:

const express = require('express');
const rateLimit = require('express-rate-limit');
const app = express();

// Rate limit to mitigate brute force: limit token validation attempts
const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // limit each token/IP to 100 requests per window
  keyGenerator: (req) => {
    // Use token or IP to scope limits
    const token = req.headers.authorization?.split(' ')[1];
    return token || req.ip;
  },
  message: { error: 'Too many requests, try again later.' },
  standardHeaders: true,
  legacyHeaders: false,
});

app.use('/api', apiLimiter);

// Bearer token validation middleware
function validateBearerToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = authHeader.split(' ')[1];
  // Compare token using a constant-time method to avoid timing leaks
  const isValid = constantTimeCompare(token, expectedToken);
  if (!isValid) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  req.user = { token }; // attach minimal user context
  next();
}

// Constant-time comparison helper to reduce timing variance
function constantTimeCompare(a, b) {
  if (a.length !== b.length) return false;
  let result = 0;
  for (let i = 0; i < a.length; i++) {
    result |= a.charCodeAt(i) ^ b.charCodeAt(i);
  }
  return result === 0;
}

app.get('/api/secure', validateBearerToken, (req, res) => {
  res.json({ message: 'Access granted' });
});

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

Additional remediation practices include:

Use cryptographically random tokens with sufficient entropy to make guessing impractical.
Bind tokens to specific scopes, audiences, and IPs where appropriate to reduce the impact of token leakage.
Implement progressive delays or temporary lockouts after repeated failures, while avoiding account denial-of-service.
Monitor and log authentication attempts to detect brute force patterns; integrate with alerting pipelines.
Ensure error messages are generic (e.g., "Unauthorized") to avoid disclosing whether a token exists.

MiddleBrick’s scans can verify whether rate limiting is applied to token-validating routes and whether responses leak information that could aid brute force attempts. The CLI (middlebrick scan <url>) and GitHub Action enable you to include these checks in development and CI/CD workflows, while the Web Dashboard helps track security posture over time.