Missing Tls in Feathersjs with Api Keys

FeathersJS is a framework for creating JavaScript and TypeScript APIs. When an API configured with API keys does not enforce Transport Layer Security (TLS), credentials are transmitted in clear text. This combination exposes the API key to network interception, enabling account takeover or privilege escalation.

An API key is a bearer credential; possession of the key is typically sufficient to authenticate and access protected endpoints. Without TLS, an attacker on the same network or positioned between the client and server can capture the key via passive sniffing or active man-in-the-middle techniques. Once captured, the key can be reused until it is rotated, regardless of other mitigations such as referrer checks or IP allowlists.

FeathersJS applications often expose REST or Socket.io transports. If TLS is missing, both channels transmit headers containing the API key in plaintext. For example, a request like GET /v1/resources with header Authorization: Bearer will expose the key on the wire. This violates the confidentiality requirement of authentication and directly weakens the security posture evaluated by the Authentication check in middleBrick scans. The scan will flag missing TLS as a high-severity finding because it enables credential exposure and may contribute to findings in related checks such as Data Exposure and Unsafe Consumption.

Compliance frameworks commonly require encryption in transit for authentication material. Without TLS, an API using API keys fails basic controls in standards such as OWASP API Security Top 10 (2023) API1:2023-Broken Object Level Authorization when combined with IDOR, and PCI-DSS requirements for protecting cardholder data. middleBrick’s Authentication check validates whether endpoints are served over TLS and reports the absence of encryption as a finding, noting that API keys must not traverse untrusted networks unprotected.

Additionally, unencrypted channels complicate secure key lifecycle management. Rotation, revocation, and audit become riskier when keys are frequently exposed. An attacker who observes a single valid key can simulate a legitimate client, and because the API relies solely on API keys for authorization, there is no secondary factor to prevent abuse. This amplifies the risk profile and can lead to findings in Authorization and Property Authorization checks if the compromised key grants elevated access.

In practice, a middleBrick scan of a FeathersJS API that uses API keys but lacks TLS will surface the issue under the Authentication category with high severity. The report will indicate that unauthenticated scanning detected plaintext transmission of credentials and recommend enforcing TLS before redeploying the service. Until TLS is applied, the API remains vulnerable regardless of other controls such as rate limiting or input validation.

Remediation centers on enforcing HTTPS for all endpoints and ensuring API keys are never transmitted over insecure channels. Below are concrete steps and code examples for a FeathersJS application using REST and authentication via API keys.

First, configure the server to use TLS. In a Node.js environment, provide the HTTPS server options when initializing the Feathers application. This ensures all HTTP traffic is redirected to HTTPS and API keys are protected in transit.

const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const https = require('https');
const fs = require('fs');

const app = express(feathers());

// Configure API key authentication
const authentication = require('@feathersjs/authentication');
const local = require('@feathersjs/authentication-local');

app.configure(authentication({
  secret: 'your-super-secret',
  path: '/authentication',
  service: 'users',
  entity: 'user',
  paginate: {
    default: 10,
    max: 50
  }
}));

app.use('/authentication', local.authentication());

// Example of an API key protected service hook
app.use('/messages', {
  async before(hook) {
    const apiKey = hook.params.headers['x-api-key'];
    if (!apiKey || apiKey !== process.env.SERVICE_API_KEY) {
      throw new Error('Not authorized');
    }
    return hook;
  }
}, {
  async get(id, params) {
    return { id, text: 'secure message' };
  }
});

const options = {
  key: fs.readFileSync('/path/to/server.key'),
  cert: fs.readFileSync('/path/to/server.cert')
};

https.createServer(options, app).listen(443, () => {
  console.log('FeathersHTTPS server running on port 443');
});

This example creates an HTTPS server using key and certificate files, ensuring that all API key validation occurs over encrypted connections. The hook checks the x-api-key header before allowing access to the service, and because the transport is encrypted, the key is not exposed to network observers.

Second, enforce HTTPS at the infrastructure or reverse-proxy level. If terminating TLS at a load balancer or Nginx, ensure the backend still listens securely or that the proxy sets headers like X-Forwarded-Proto which Feathers can use to reject non-TLS requests.

// Feathers app configured to trust reverse proxy and reject non-HTTPS
const app = express(feathers());

// Trust the proxy to set protocol correctly
app.set('trust proxy', true);

// Middleware to enforce HTTPS
app.use((req, res, next) => {
  if (req.secure !== true) {
    return res.status(403).send('HTTPS required');
  }
  next();
});

app.configure(authentication({ /* options */ }));

Third, rotate API keys regularly and store them securely using environment variables or a secrets manager. Avoid hardcoding keys in source code or configuration files that may be committed to version control. In a containerized deployment, mount secrets at runtime and ensure that logs do not accidentally capture key values from headers.

Finally, validate that the fix is effective by running a middleBrick scan. The dashboard will show an improved Authentication score once TLS is enforced and the API no longer transmits API keys in plaintext. The CLI can be used in CI/CD to fail builds if endpoints are detected without encryption, providing continuous assurance that API keys remain protected during development and deployment.