Credential Stuffing in Express with Api Keys

Credential stuffing is an automated attack technique in which previously breached username and password pairs are systematically submitted to sign-in endpoints to exploit reused credentials. When an Express API relies solely on static API keys for authentication—especially when those keys are passed in headers, query parameters, or logs—it can inadvertently turn into a credential-stuffing target if key management practices are weak.

Express applications often expose API key validation in middleware that runs before route handlers. If the validation logic does not tightly control where keys are sourced from and how they are compared, attackers can iterate over leaked key lists and observe subtle timing differences or error message variations to infer validity. For example, an endpoint like /api/v1/reports that accepts an x-api-key header may return 401 for malformed keys and 403 for valid but insufficient scopes. This behavioral distinction can be probed automatically at scale.

Another risk vector arises when API keys are stored or logged insecurely. In development or misconfigured production environments, keys might be written to console output or to structured logs that are accessible to unauthorized parties. These logs become a data source for attackers performing credential stuffing or credential harvesting, because the leaked keys can be replayed directly against the API. Even if rate limiting exists, keys are typically long-lived compared to session tokens, increasing the window of exposure.

Additionally, if the Express app also supports multiple authentication schemes—such as cookie-based sessions alongside API keys—attackers may exploit inconsistent authorization checks. A route that correctly enforces key validation for one method but falls back to weaker checks for another can create privilege escalation paths. For instance, an administrative route that accepts both a key and a user token might inadvertently authorize a lower-privilege key if the token validation is skipped under certain conditions.

Because middleBrick tests unauthenticated attack surfaces, it can detect subtle timing or status-code anomalies that suggest key validation inconsistencies, alongside missing protections like rate limiting, input validation, and encryption. These checks help surface weaknesses before attackers leverage them in large-scale credential stuffing campaigns.

Secure handling of API keys in Express requires strict validation, controlled exposure, and defense-in-depth measures. The following examples demonstrate hardened patterns that reduce the risk of credential stuffing and key misuse.

Constant-time comparison and scope validation

Always compare API keys using a constant-time function to prevent timing attacks, and validate associated scopes or permissions before processing the request.

const crypto = require('crypto');

function safeKeyCompare(a, b) {
  return crypto.timingSafeEqual(Buffer.from(a), Buffer.from(b));
}

const VALID_KEYS = new Set([
  'pub_abc123',
  'sec_xyz789'
]);

function validateApiKey(req, res, next) {
  const key = req.headers['x-api-key'];
  if (!key || !VALID_KEYS.has(key)) {
    return res.status(401).json({ error: 'invalid_key' });
  }
  // Attach key metadata for downstream use
  req.apiKey = { id: key, scope: key.startsWith('pub_') ? 'read' : 'admin' };
  next();
}

app.use('/api/v1/reports', validateApiKey);

Avoid logging sensitive keys

Ensure API keys are never written to logs or error messages. Sanitize output and use structured logging that redacts sensitive fields.

const logger = {
  info: (message, meta) => {
    const { apiKey, ...safeMeta } = meta || {};
    console.info(message, safeMeta);
  },
  error: (message, err) => {
    // Avoid logging stack traces with key context
    console.error(message, { error: err && err.message });
  }
};

app.use((req, res, next) => {
  logger.info('request', { method: req.method, path: req.path, apiKey: req.headers['x-api-key'] });
  next();
});

Rate limiting and key rotation support

Apply rate limiting at the key level to mitigate automated stuffing attempts, and design key rotation workflows to limit the impact of leaked keys.

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

const keyLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 60,
  keyGenerator: (req) => req.headers['x-api-key'] || req.ip,
  message: { error: 'rate_limit_exceeded' },
  standardHeaders: true,
  legacyHeaders: false,
});

app.use('/api/v1/reports', keyLimiter);

Transport encryption and key transmission

Always enforce HTTPS and avoid transmitting API keys in URLs or query strings. Use headers and, when possible, short-lived tokens derived from keys.

// Enforce HTTPS in production
app.use((req, res, next) => {
  if (process.env.NODE_ENV === 'production' && !req.secure) {
    return res.status(400).json({ error: 'insecure_transport' });
  }
  next();
});

Operational practices

• Store keys in environment variables or a secrets manager; never commit them to source control.
• Rotate keys regularly and invalidate compromised keys immediately.
• Use different keys per integration or client to contain blast radius.
• Monitor for anomalous request patterns, such as repeated 401s from a single key.

These measures align with broader API security checks such as input validation, encryption, and rate limiting, which middleBrick evaluates as part of its unauthenticated scans. The tool can highlight misconfigurations—such as missing transport enforcement or verbose error messages—that increase the effectiveness of credential stuffing attempts.