Api Key Exposure in Loopback with Mutual Tls

Loopback is a widely used Node.js framework for building APIs. When mutual TLS (mTLS) is used, the client presents a certificate in addition to the server verifying its identity. This setup can inadvertently expose API keys if application logic mishandles certificate-derived metadata or if keys are passed in headers that bypass intended access controls.

mTLS authenticates the client and can enforce strict authorization based on certificate attributes (subject, issuer, SAN). However, developers sometimes map certificate fields to internal identifiers and then use those identifiers to look up secrets such as API keys from a database or configuration store. If the mapping is overly permissive or if debug information is returned in error responses, the API key may be reflected back to the client or logged in plaintext.

A common pattern is to read the client certificate from the TLS socket and extract the subject or a custom extension. For example:

const fs = require('fs');
const https = require('https');
const loopback = require('loopback');
const app = loopback();

const serverOptions = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
  requestCert: true,
  rejectUnauthorized: true,
};

https.createServer(serverOptions, (req, res) => {
  const cert = req.socket.getPeerCertificate ? req.socket.getPeerCertificate() : null;
  if (cert && cert.subject) {
    // Example: using certificate subject to identify client and fetch API key
    const clientId = cert.subject.CN; // caution: may be spoofed if mTLS not enforced properly upstream
    // Lookup API key for clientId — ensure this lookup is secure and rate-limited
    res.setHeader('X-API-Key', lookupApiKeyForClient(clientId));
  }
  res.end('ok');
}).listen(8443);

In this scenario, if the API key is returned in a header or included in a response body due to a coding mistake, it can be exposed to an authenticated client. Additionally, if the server does not properly validate the certificate chain and relies only on the presence of a cert, an attacker with a valid certificate issued by a trusted CA could gain access and extract keys through error messages or misconfigured logging.

Another risk arises when the API key is used as a bearer token downstream and the client certificate is not also enforced on that downstream service. An attacker who can observe or inject traffic between services might capture the key if TLS termination occurs at a different layer without consistent mTLS enforcement. Logging or error handling that includes the key value compounds the exposure.

To detect such issues, scans should check whether API keys are returned in response headers or bodies, whether certificate validation is strict, and whether sensitive data is logged. middleBrick’s LLM/AI Security checks can identify patterns where keys might be inadvertently echoed, and its Data Exposure checks help highlight insecure transmission or logging practices.

Remediation focuses on strict certificate validation, avoiding key exposure in responses or logs, and ensuring consistent mTLS across all service hops.

Strict Certificate Validation and Minimal Data Exposure

Do not echo API keys or certificate metadata in responses. Instead, use certificate information strictly for authorization decisions and keep sensitive data server-side.

const fs = require('fs');
const https = require('https');
const loopback = require('loopback');
const app = loopback();

const serverOptions = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
  requestCert: true,
  rejectUnauthorized: true,
};

function getClientIdFromCert(cert) {
  // Use a stable identifier from certificate extensions or SAN, not just CN
  if (cert.subject && cert.subject.O) {
    return cert.subject.O; // organization as a stable identifier
  }
  return null;
}

function authorizeClient(clientId) {
  // Perform server-side authorization, e.g., check against a permissions store
  return true; // simplified
}

https.createServer(serverOptions, (req, res) => {
  const cert = req.socket.getPeerCertificate ? req.socket.getPeerCertificate() : null;
  if (!cert || !cert.subject) {
    res.statusCode = 400;
    res.end('Client certificate required');
    return;
  }

  const clientId = getClientIdFromCert(cert);
  if (!clientId || !authorizeClient(clientId)) {
    res.statusCode = 403;
    res.end('Forbidden');
    return;
  }

  // Do not set API key in headers; use server-side context for downstream calls
  res.end('access granted');
}).listen(8443, () => console.log('mTLS server running on port 8443'));

Consistent mTLS Enforcement Across Services

Ensure that any service consuming the API also enforces mTLS and does not treat the API key as a bearer token over non-mTLS channels. Use environment-controlled configuration to rotate keys and certificates and avoid embedding keys in logs.

const axios = require('axios');
const fs = require('fs');

const agent = new axios.Agent({
  key: fs.readFileSync('client-key.pem'),
  cert: fs.readFileSync('client-cert.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
});

async function callSecureService() {
  try {
    const response = await axios.get('https://api.example.com/v1/resource', {
      httpsAgent: agent,
      // Do not pass API keys in headers when mTLS is used for client identification
    });
    console.log(response.data);
  } catch (error) {
    // Avoid logging stack traces or responses that might contain sensitive data
    console.error('Request failed:', error.message);
  }
}

callSecureService();

These examples demonstrate how to enforce mTLS in Loopback applications while minimizing the risk of API key exposure. Combine these practices with runtime scanning to validate that mTLS is correctly configured and that no sensitive data is inadvertently exposed.