Missing Tls in Feathersjs with Basic Auth
Missing Tls in Feathersjs with Basic Auth — how this specific combination creates or exposes the vulnerability
FeathersJS is a framework for creating JavaScript APIs with REST and Socket.io transports. When Basic Authentication is used without Transport Layer Security (TLS), credentials are transmitted in an easily recoverable format. Basic Auth encodes the username and password with Base64, which provides no confidentiality. An attacker conducting unauthenticated network interception or compromising a network segment can capture these encoded values and decode them trivially.
middleBrick’s unauthenticated scan checks for the absence of TLS on endpoints that accept credentials. During the Authentication check, it observes whether credentials are exchanged without encryption. If a FeathersJS endpoint exposes a login route or accepts the Authorization header over HTTP, the scan flags the Missing Tls finding. This is distinct from implementation bugs; it is a transport-layer gap that makes any credential protection ineffective.
In a typical FeathersJS service, hooks can validate presence of credentials but cannot prevent the exposure that occurs before application logic runs. For example, a service file may enforce authentication via a hook, but if the server listens on HTTP rather than HTTPS, the initial credentials sent by the client are already exposed. The scan’s unauthenticated attack surface testing detects this by attempting to observe authentication exchanges without client certificates or other mitigations. The tool also cross-references an OpenAPI specification if provided, confirming whether the scheme is declared as https and highlighting discrepancies between declared transport and observed behavior.
The LLM/AI Security checks are not directly engaged for Missing Tls, but the scanner’s inventory and input validation checks may note that unencrypted channels place credentials at risk of interception, replay, and logging. Findings include the lack of server-side redirection from HTTP to HTTPS and missing HTTP Strict Transport Security (HSTS) headers, which prevent downgrade attacks. Remediation guidance centers on enforcing TLS for all endpoints, particularly those under /authentication or any route exchanging tokens or session identifiers.
Basic Auth-Specific Remediation in Feathersjs — concrete code fixes
To secure FeathersJS with Basic Authentication, you must terminate TLS at the proxy or server and ensure the application only listens on HTTPS. Below are concrete steps and code examples.
1. Enforce HTTPS at the network or reverse proxy level
Use a reverse proxy (e.g., NGINX, Caddy, or a cloud load balancer) to handle TLS termination. The proxy accepts HTTPS from clients and forwards unencrypted traffic to your FeathersJS app on localhost. This limits the exposed surface and avoids managing certificates inside the app process.
2. Configure FeathersJS to require secure transport
In your server entrypoint, configure the HTTP adapter to reject insecure requests or to redirect HTTP to HTTPS. The exact mechanism depends on your adapter, but the principle is to ensure the server does not serve unencrypted responses.
3. Example: HTTPS server with Basic Auth hook
Assume you use Express-compatible HTTP server in FeathersJS. You create an HTTPS server using Node.js https module and apply Basic Auth via a before hook that checks the Authorization header.
const https = require('https');
const fs = require('fs');
const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const app = express(feathers());
// Example Basic Auth hook
app.hooks({
before: {
all: [context => {
const auth = context.params.headers.authorization || '';
const match = auth.match(/^Basic\s+(\S+)$/);
if (!match) {
throw new Error('Unauthorized');
}
const decoded = Buffer.from(match[1], 'base64').toString('utf8');
const [username, password] = decoded.split(':');
if (username !== 'admin' || password !== 'S3cur3P@ss') {
throw new Error('Invalid credentials');
}
// Remove the header to avoid accidental logging
delete context.params.headers.authorization;
return context;
}]
}
});
// Configure your services here
// app.configure(rest());
// app.configure(socketio());
const serverOptions = {
key: fs.readFileSync('/etc/ssl/private/server.key'),
cert: fs.readFileSync('/etc/ssl/certs/server.crt')
};
https.createServer(serverOptions, app).listen(8443, () => {
console.log('HTTPS Feathers server running on port 8443');
});
4. Validate transport in an OpenAPI spec
If you provide an OpenAPI specification to middleBrick, ensure the scheme is https and that security schemes reference the Authorization header using the Basic scheme. The scanner will align spec definitions with runtime behavior and flag mismatches such as a declared HTTPS scheme while the server listens on HTTP.
5. Complementary headers and practices
Even when using a proxy, set headers that mitigate certain risks. For example, use X-Forwarded-Proto to inform your app about the original protocol, and ensure cookies include Secure and HttpOnly attributes. Avoid logging authorization headers to prevent credential leakage in log stores.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |