Padding Oracle in Express with Api Keys

A padding oracle attack in an Express API that uses API keys typically involves two conditions: (1) the server decrypts request data (e.g., a JSON payload, cookie, or URL parameter) using a block cipher in a mode like CBC, and (2) the server reveals decryption validity through distinct error behaviors or timing differences. When API keys are used for authentication but the encrypted data itself is crafted or tampered with, an attacker can exploit the server’s error responses to gradually recover plaintext without knowing the key.

In Express, this often manifests when developers use API keys to authorize requests but then process encrypted payloads (such as tokens or stored data) with a cipher that does not provide integrity protection. For example, if an endpoint accepts an encrypted blob in a header or body, uses a static initialization vector (IV), or compares decrypted bytes in a non-constant-time manner, an attacker can send modified ciphertexts and observe differences in HTTP status codes, response messages, or timing to infer whether a padding block is valid. These validity signals constitute an oracle, enabling iterative decryption of the ciphertext byte by byte.

Consider an Express route that decrypts a JSON Web Token-like structure encrypted with AES-248-CBC, verifies an API key in a custom header, and then parses the decrypted JSON. If the server returns a 400 with 'Invalid padding' for bad padding and a 401 with 'Invalid signature' for a valid pad but bad authentication, it unintentionally exposes a padding oracle. An attacker can use this behavioral distinction to mount a padding oracle attack even though API key authentication is present, because the decryption step occurs before or independently of key validation, and error messages differ based on padding correctness.

Real-world attack patterns align with OWASP API Top 10 cryptographic weaknesses and can map to findings in categories such as Input Validation and Data Exposure. The presence of API keys does not prevent padding oracle; it only secures access to the endpoint after decryption. Without integrity checks (e.g., an HMAC or authenticated encryption like AES-GCM), encrypted data remains malleable, and the server’s error handling may leak information that makes decryption feasible over multiple requests.

To illustrate, an attacker might intercept a ciphertext and tweak bytes in the last block, sending many requests to observe whether responses contain 'Invalid padding' versus other errors. By aggregating these oracle responses, they can recover the plaintext. This demonstrates why the combination of Express, API keys, and weak cryptographic handling is risky: authentication and confidentiality are not achieved when decryption oracles exist.

Remediation focuses on removing oracle behavior and ensuring API keys are used within a robust cryptographic workflow. Use authenticated encryption, constant-time comparisons, and avoid returning padding-specific errors.

1. Use authenticated encryption (AES-GCM)

Replace CBC with AES-GCM so decryption fails entirely if the ciphertext is altered, and do not expose padding errors.

const crypto = require('crypto');
const algorithm = 'aes-248-gcm';

function decryptWithAuth(ciphertext, key, nonce, authTag) {
  const decipher = crypto.createDecipheriv(algorithm, key, nonce);
  decipher.setAuthTag(authTag);
  let decrypted = decipher.update(ciphertext, 'base64', 'utf8');
  decrypted += decipher.final('utf8');
  return JSON.parse(decrypted);
}

2. Constant-time API key comparison

Prevent timing leaks when validating API keys by using a constant-time comparison.

const crypto = require('crypto');

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

// In your route
const expected = process.env.API_KEY_HASH;
const received = req.headers['x-api-key'];
if (!received || !safeKeyCompare(received, expected)) {
  return res.status(401).json({ error: 'Unauthorized' });
}

3. Unified error handling

Return the same generic error for bad ciphertext, bad padding, and authentication failures to eliminate oracle distinctions.

app.post('/data', (req, res) => {
  const ciphertext = req.body.encrypted;
  const receivedKey = req.headers['x-api-key'];
  if (!safeKeyCompare(receivedKey, process.env.API_KEY_HASH)) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  try {
    const payload = decryptWithAuth(ciphertext, KEY, nonce, authTag);
    res.json(payload);
  } catch (err) {
    // Do not differentiate between padding and other failures
    return res.status(400).json({ error: 'Invalid request' });
  }
});

4. Validate and scope API keys

Ensure API keys are not used as cryptographic keys. Use keys for access control only, and keep encryption keys separate. Rotate keys and store them securely (e.g., environment variables or secret manager).

These steps reduce the attack surface by eliminating padding oracles and ensuring API keys govern authorization without influencing cryptographic integrity. They complement broader measures such as input validation and secure dependency management.