Logging Monitoring Failures in Feathersjs with Api Keys

FeathersJS is a framework for building JavaScript APIs with real-time capabilities. When using API keys for authentication, logging and monitoring failures can expose whether a key is valid without proper safeguards. For example, if your service emits distinct logs for an invalid key versus a missing key, an attacker can enumerate valid keys through controlled requests and observe log behavior or infer existence via monitoring dashboards.

Consider a typical FeathersJS service configured with an authentication hook that checks an API key:

// src/hooks/authenticate-key.js
module.exports = function () {
  return async context => {
    const { apikey } = context.params.query;
    if (!apikey) {
      throw new Error('API key is missing');
    }
    const isValid = await context.app.service('api-keys').Model.findOne({ apikey });
    if (!isValid) {
      throw new Error('Invalid API key');
    }
    context.params.apikey = isValid;
    return context;
  };
};

If the hook throws different error messages or status codes for missing versus invalid keys, and these are captured in structured logs (e.g., with a logging transport that records request metadata), monitoring systems can correlate failed attempts with specific key patterns. This becomes a disclosure vector in environments where logs are accessible to attackers or where monitoring alerts expose rate spikes tied to key validation failures.

Moreover, if instrumentation (like tracing IDs) is included in logs and monitoring dashboards display per-key request metrics, an attacker can use timing or error-rate deviations to detect active keys. Insecure default logging levels may also inadvertently expose stack traces or internal paths when a key validation fails, aiding reconnaissance. The risk is not that API keys themselves are weak, but that operational feedback loops—logs and monitors—turn authentication events into signals that reduce attacker effort.

To align with middleBrick’s findings on Authentication and BOLA/IDOR checks, such feedback must be minimized. The scanner tests whether responses and logs (as observable through error messages and status codes) leak whether a key is valid, and whether monitoring configurations expose sensitive patterns. Remediation focuses on making authentication outcomes indistinguishable and ensuring logging does not amplify differences between failure modes.

Remediation in FeathersJS should ensure that authentication responses are uniform and that logs do not expose key validity. Use a constant-time comparison pattern and throw a single generic error for any authentication failure. Avoid branching logic that reveals whether a key is missing or incorrect.

Example of a secure hook that prevents enumeration via logs and monitoring:

// src/hooks/authenticate-key-secure.js
const crypto = require('crypto');

// Constant-time dummy check to avoid timing leaks
function safeCompare(input, stored) {
  const inputBuf = Buffer.from(input || '');
  const storedBuf = Buffer.from(stored || '');
  if (inputBuf.length !== storedBuf.length) {
    // Use constant-time comparison by comparing same-length dummy data
    crypto.timingSafeEqual(Buffer.alloc(32, 0), Buffer.alloc(32, 0));
    return false;
  }
  return crypto.timingSafeEqual(inputBuf, storedBuf);
}

module.exports = function () {
  return async context => {
    const provided = context.params.query.apikey;
    // Use a stored key from a secure source; here we simulate retrieval
    const storedKey = process.env.API_KEY_SECRET;
    if (!provided || !storedKey) {
      // Generic failure to avoid signaling missing vs invalid
      throw new Error('Unauthorized');
    }
    if (!safeCompare(provided, storedKey)) {
      throw new Error('Unauthorized');
    }
    // Attach resolved key metadata if needed, without revealing validation details
    context.params.apikey = { status: 'valid' };
    return context;
  };
};

In this pattern, the response status and error message remain the same regardless of whether the key is missing or invalid. The safeCompare function mitigates timing attacks, and the hook avoids early returns that could produce different stack traces or log paths.

Additionally, configure your logging transport to redact or omit the API key from request logs. For example, if you use a logging library, ensure the key is excluded from metadata:

// Example with a generic logger (pseudocode, adapt to your logger)
app.set('logger', {
  info: (message, meta) => {
    const { apikey, ...safeMeta } = meta;
    logger.info(message, { ...safeMeta, requestId: meta.requestId });
  }
});

For monitoring, avoid creating per-key dashboards or alerts that can be probed. Instead, monitor aggregate authentication failure rates and anomaly detection on request patterns. If you adopt the Pro plan, continuous monitoring can be added to your API suite to flag authentication anomalies without exposing key-specific signals; the GitHub Action can enforce a maximum failure threshold in CI/CD, and the Web Dashboard can help track trends over time.

Finally, ensure your OpenAPI spec does not document the API key in examples or descriptions that could be exposed in generated docs. Use middleBrick’s OpenAPI/Swagger analysis to confirm that spec definitions align with runtime behavior and that no references to keys leak into public-facing documentation.