Data Exposure in Hapi with Mutual Tls

The Data Exposure check in middleBrick examines whether sensitive information such as authentication credentials, personal data, or session tokens is transmitted without adequate protection or inadvertently disclosed in responses. When assessing a Hapi server that uses Mutual TLS (mTLS), the scanner considers both the transport-layer guarantees of mTLS and how the application handles client certificates and related data.

Mutual TLS ensures that both client and server authenticate each other using X.509 certificates. In Hapi, this is typically enforced by configuring the TLS layer to request and validate client certificates. However, even with mTLS in place, data exposure risks can arise in several specific configurations common in Hapi setups:

• Certificate metadata leakage: If a Hapi server logs or echoes certificate details (such as subject distinguished names or serial numbers) in access logs, error responses, or custom headers, sensitive identity information may be exposed to unauthorized parties.
• Improper certificate handling: Failing to validate client certificates properly or inadvertently passing certificate objects to request handlers can lead to sensitive data being included in responses or debug output.
• Mixed content and weak cipher suites: Using deprecated protocols or weak cipher suites with mTLS can expose session data to interception, even when client authentication is enforced.
• Insecure default routes or error handling: Routes that do not require mTLS or that expose stack traces and internal errors may leak paths, certificate requirements, or server details to unauthenticated clients.

During a scan, middleBrick tests unauthenticated endpoints and inspects response headers, body content, and observable behaviors to detect patterns such as certificate fields in logs or responses, missing strict TLS requirements, and routes that bypass client verification. These findings highlight configuration or implementation gaps where data exposure can occur despite the presence of mTLS in Hapi.

To mitigate data exposure risks in a Hapi server using Mutual TLS, apply strict transport settings and careful handling of certificate data. The following patterns demonstrate secure configurations and coding practices.

Enforce mTLS in Hapi with explicit certificate validation

Ensure the server requests and validates client certificates and rejects connections that do not present a valid cert. Use the built-in TLS options and avoid permissive settings.

const Hapi = require('@hapi/hapi');
const fs = require('fs');

const init = async () => {
  const server = Hapi.server({
    port: 443,
    tls: {
      key: fs.readFileSync('/path/to/server-key.pem'),
      cert: fs.readFileSync('/path/to/server-cert.pem'),
      ca: [fs.readFileSync('/path/to/ca-cert.pem')],
      requestCert: true,
      rejectUnauthorized: true
    }
  });

  server.route({
    method: 'GET',
    path: '/secure',
    options: {
      // Require TLS auth for this route; handler can read req.socket.getPeerCertificate()
      auth: false // TLS enforced at transport layer above
    },
    handler: (request, h) => {
      const cert = request.socket.getPeerCertificate();
      // Avoid logging or exposing certificate details
      if (!cert || Object.keys(cert).length === 0) {
        throw Boom.unauthorized('Client certificate required');
      }
      return { message: 'Authenticated via mTLS' };
    }
  });

  await server.start();
  console.log('Server running on %s', server.info.uri);
};

init().catch(err => {
  console.error(err);
  process.exit(1);
});

Avoid leaking certificate metadata in responses and logs

Do not include certificate fields such as subject or serial in responses. Sanitize logs and ensure error handlers do not expose sensitive context.

// Bad: exposing certificate info
server.route({
  method: 'GET',
  path: '/debug',
  handler: (request, h) => {
    const cert = request.socket.getPeerCertificate();
    return { clientSubject: cert.subject }; // Data exposure risk
  }
});

// Good: minimal handling, no sensitive details returned
server.route({
  method: 'GET',
  path: '/status',
  handler: () => ({ status: 'ok' })
});

Use strong cipher suites and modern TLS versions

Configure the TLS context to prefer strong ciphers and disable outdated protocols to prevent session data exposure.

const server = Hapi.server({
  port: 443,
  tls: {
    key: fs.readFileSync('/path/to/server-key.pem'),
    cert: fs.readFileSync('/path/to/server-cert.pem'),
    ca: [fs.readFileSync('/path/to/ca-cert.pem')],
    requestCert: true,
    rejectUnauthorized: true,
    ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256',
    minVersion: 'TLSv1.2'
  }
});

Apply consistent authentication and route-level protections

Combine transport-level mTLS with application-level authentication where needed, and ensure all routes enforce secure defaults. Use Hapi’s auth strategies to complement TLS, and avoid routes that bypass verification.

const Bcrypt = require('bcrypt');

// Example of combining TLS with an API key strategy for sensitive routes
server.auth.strategy('api-key', 'api-key', {
  keys: ['super-secret-key']
});

server.route({
  method: 'POST',
  path: '/data',
  options: {
    auth: 'api-key',
    tls: {
      cert: fs.readFileSync('/path/to/server-cert.pem'),
      key: fs.readFileSync('/path/to/server-key.pem'),
      ca: [fs.readFileSync('/path/to/ca-cert.pem')],
      requestCert: true,
      rejectUnauthorized: true
    }
  },
  handler: (request, h) => {
    // Process data with both TLS and API key validated
    return { received: true };
  }
});