Api Key Exposure in Restify with Api Keys

Api Key Exposure in Restify occurs when API keys are handled in ways that allow unauthorized access or leakage during request processing. Restify is a Node.js HTTP server framework commonly used to build APIs, and it often integrates API key mechanisms for authentication. When keys are passed in URLs, headers, or logs without protection, or when routes inadvertently expose key values, the framework’s runtime behavior can reveal sensitive credentials.

One common pattern is validating API keys via headers in a Restify server. If the server echoes the key in responses or logs it verbatim, an attacker who can trigger error messages or inspect logs may recover the key. For example, a route that logs incoming headers including the Authorization header can print the key to stdout or a file accessible to unintended parties:

const restify = require('restify');
const server = restify.createServer();

server.use((req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  console.log('Incoming API key:', apiKey); // Risk: logs sensitive key
  return next();
});

server.get('/resource', (req, res, next) => {
  const key = req.headers['x-api-key'];
  if (key !== process.env.API_KEY) {
    return next(new restify.UnauthorizedError('Invalid key'));
  }
  res.send({ data: 'ok' });
  return next();
});

server.listen(8080, () => console.log('Listening'));

In this pattern, if an attacker causes an error or triggers verbose logging (e.g., by sending malformed requests), the console output may reveal the API key. Additionally, if the server returns stack traces or detailed errors in development mode, keys included in route parameters or query strings can be exposed through URLs, which are often stored in server logs or browser history.

Another exposure vector arises when API keys are embedded in route handlers or middleware conditionally, and those routes are publicly accessible. An attacker probing endpoints with tools can infer valid keys by observing differences in behavior or timing, leading to unauthorized access to protected resources. This aligns with BOLA/IDOR and Unsafe Consumption checks in middleBrick’s scan, which flag routes where keys are used without proper authorization context or where responses leak sensitive information.

Furthermore, if the Restify server streams responses or uses plugins that serialize request contexts for debugging, API keys may be captured in external systems outside the application’s control. middleBrick’s Data Exposure and Logging checks identify such risks by analyzing endpoint behavior and response contents, ensuring that keys are not reflected in outputs or metadata.

Lastly, when OpenAPI specs are published alongside a Restify implementation, descriptions or examples that include real API keys can lead to accidental exposure. middleBrick’s OpenAPI/Swagger analysis resolves $ref chains and cross-references spec definitions with runtime findings to detect mismatches where documentation inadvertently exposes credentials used in examples.

To remediate Api Key Exposure in Restify, refactor how keys are handled, stored, and logged. The goal is to ensure keys are never echoed, persisted in logs, or exposed in responses or URLs.

First, avoid logging sensitive headers. Instead of logging the raw key, log only whether authentication succeeded:

const restify = require('restify');
const server = restify.createServer();

server.use((req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (!apiKey) {
    return next(new restify.UnauthorizedError('Missing key'));
  }
  const isValid = apiKey === process.env.API_KEY;
  // Log only the result, not the key itself
  console.log('API key validation result:', isValid ? 'valid' : 'invalid');
  if (!isValid) {
    return next(new restify.UnauthorizedError('Invalid key'));
  }
  return next();
});

server.get('/resource', (req, res, next) => {
  res.send({ data: 'ok' });
  return next();
});

server.listen(8080, () => console.log('Listening'));

Second, store keys in environment variables and reference them securely. Never hardcode keys in source files or route definitions. Use process.env with a strict validation check, and ensure the environment is configured securely outside the application code.

Third, ensure error responses do not reveal key presence. Avoid returning messages that differentiate between ‘key missing’ and ‘key invalid’ in a way that leaks information. Instead, use a generic unauthorized response:

server.use((req, res, next) => {
  const providedKey = req.headers['x-api-key'];
  const expectedKey = process.env.API_KEY;
  const isValid = providedKey && crypto.timingSafeEqual(
    Buffer.from(providedKey),
    Buffer.from(expectedKey)
  );
  if (!isValid) {
    return next(new restify.UnauthorizedError('Unauthorized'));
  }
  return next();
});

Use crypto.timingSafeEqual to prevent timing attacks when comparing keys. This requires keys to be of equal length, so normalize inputs (e.g., hash keys before comparison if lengths vary) to avoid errors.

Fourth, audit routes and middleware to ensure no endpoint reflects API keys in responses. Scan responses for accidental inclusion of key-like values and sanitize outputs. middleBrick’s Property Authorization and Input Validation checks can help identify routes where keys might be reflected or where input handling is insufficient.

Finally, integrate the GitHub Action to enforce security in CI/CD. Define a threshold so that if a scan detects API key exposure or related misconfigurations, the build fails before deployment. This prevents insecure Restify configurations from reaching production.