Side Channel Attack in Express with Basic Auth

A side channel attack in an Express service that uses HTTP Basic Auth occurs when an attacker infers sensitive information not through direct authentication bypass, but by observing timing differences, error behavior, or metadata in requests and responses. Even though Basic Auth transmits credentials in an Authorization header as base64-encoded (not encrypted) values, the application’s handling of those credentials can leak information through observable behavior.

Consider an Express route that validates credentials and performs additional operations, such as database lookups or file access, before returning a standardized 401 response. An attacker can measure response times: a valid username with an invalid password may take longer if the code performs a user lookup or password hash comparison, whereas an entirely unknown username may short-circuit earlier. These timing discrepancies can reveal whether a username exists, enabling user enumeration without ever cracking the password hash directly.

Basic Auth also tends to encourage the storage or handling of credentials in less secure ways, such as logging authorization headers for debugging or failing to consistently enforce TLS. If logs inadvertently capture Authorization headers, credentials are exposed in plaintext or base64. Similarly, inconsistent use of HTTPS can expose credentials in transit, and error messages may disclose whether the username format was recognized or whether internal processing failed. Attackers can combine these side channels—timing, logs, and error messages—to build a profile of valid users and refine further attacks like credential stuffing or phishing.

In the context of an automated security scan that tests unauthenticated attack surfaces, these side channels manifest as inconsistencies in response codes, timing, or returned headers across otherwise identical requests. For example, submitting a malformed Authorization header or varying the username portion can produce subtly different behaviors that an observant scanner or attacker can detect. Such findings highlight the importance of ensuring that authentication paths execute in constant time, avoid logging sensitive headers, and enforce transport security uniformly.

To mitigate side channel risks with HTTP Basic Auth in Express, design authentication logic to run in constant time and avoid branching on sensitive data. Avoid early returns based on username existence, and standardize error responses and timing for all authentication failures. Always enforce HTTPS in production to protect credentials in transit, and avoid logging or echoing Authorization headers.

Below are concrete Express code examples demonstrating secure handling of Basic Auth credentials.

// Secure Basic Auth middleware for Express
import express from 'express';
import { timingSafeEqual } from 'node:crypto';
import { createHash } from 'node:crypto';

const app = express();

// In-memory store for example purposes; prefer a hashed lookup in production
const users = [
  {
    username: 'alice',
    // Store precomputed hash of 'correct-horse-battery-staple' (UTF-8)
    passwordHash: createHash('sha256').update('correct-horse-battery-staple', 'utf8').digest(),
  },
];

function base64ToBuffer(b64) {
  return Buffer.from(b64, 'base64');
}

function verifyCredential(inputPassword: string, storedHash: Buffer): boolean {
  const inputHash = createHash('sha256').update(inputPassword, 'utf8').digest();
  // Ensure hashes are the same length before using timingSafeEqual
  if (inputHash.length !== storedHash.length) {
    return false;
  }
  return timingSafeEqual(inputHash, storedHash);
}

app.use((req, res, next) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Basic ')) {
    // Return a standardized response without revealing missing vs malformed auth
    res.set('WWW-Authenticate', 'Basic realm="secure"');
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = auth.split(' ')[1];
  let decoded: Buffer;
  try {
    decoded = base64ToBuffer(token);
  } catch {
    res.set('WWW-Authenticate', 'Basic realm="secure"');
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const [inputUser, inputPassBuffer] = decoded.toString().split(':');
  if (!inputUser || !inputPassBuffer) {
    res.set('WWW-Authenticate', 'Basic realm="secure"');
    return res.status(401).json({ error: 'Unauthorized' });
  }

  // Constant-time comparison across users
  let found = false;
  let candidateHash: Buffer | null = null;
  for (const user of users) {
    if (user.username === inputUser) {
      found = true;
      candidateHash = user.passwordHash;
    }
  }
  // Always perform a comparison to keep timing consistent when a user is found
  const dummyHash = createHash('sha256').update('dummy', 'utf8').digest();
  const compareHash = candidateHash || dummyHash;
  const match = verifyCredential(inputPassBuffer.toString(), compareHash);

  if (found && match) {
    req.user = { username: inputUser };
    return next();
  }

  res.set('WWW-Authenticate', 'Basic realm="secure"');
  return res.status(401).json({ error: 'Unauthorized' });
});

app.get('/profile', (req: express.Request, res) => {
  res.json({ user: (req as any).user?.username || 'guest' });
});

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

Key remediation points illustrated:

• Standardized 401 responses with WWW-Authenticate header to avoid signaling whether a username exists.
• Use of timingSafeEqual to compare hashes in constant time, preventing timing side channels.
• Always performing a hash comparison (even with a dummy hash) when username presence varies, to normalize execution time.
• Avoiding logging of Authorization headers and ensuring TLS is enforced in production deployments.

For teams using middleBrick, run a scan to validate that your authentication endpoints do not exhibit timing inconsistencies or leak user enumeration through response behavior. The CLI tool allows quick checks from the terminal: middlebrick scan <url>, while the Web Dashboard and Pro plan continuous monitoring help track security posture over time.