Missing Tls in Fiber with Basic Auth

Transport Layer Security (TLS) is the baseline network protection that prevents on-path observers from reading or altering HTTP traffic. When a Fiber service uses HTTP Basic Authentication over an unencrypted connection, credentials are encoded but not encrypted. The Base64 encoding used by Basic Auth is easily reversible and provides no confidentiality. An attacker who can observe or intercept traffic—such as on shared Wi‑Fi, a compromised network hop, or an unterminated load balancer—can decode the header and recover the username and password in clear text.

Consider the typical pattern where Basic Auth is implemented directly in Fiber handlers without TLS termination or enforcement. In such a setup, the Authorization header is sent with every request. A risk scan (e.g., via middleBrick) will flag this as a Data Exposure and Encryption finding because the credentials traverse the network in a reversible format. If the service also exposes an unauthenticated endpoint that echoes headers or reflects input, the issue can compound with other findings such as Input Validation or SSRF, since attackers may probe how the service behaves with malformed or malicious requests. Even without exploiting other vulnerabilities, the absence of TLS means that session hijacking or credential replay becomes trivial for an observer who can capture the traffic.

middleBrick’s unauthenticated scan will detect the missing TLS and, because Basic Auth is in use, will raise the severity of related findings. The scanner does not test authentication mechanisms directly but will observe that credentials are transmitted in an easily decodable format and that no transport-layer encryption is in place. This combination is especially dangerous because Basic Auth is often used for simplicity in internal or legacy services, where operators may assume network isolation is sufficient. In practice, networks are rarely isolated, and services often migrate across environments, increasing the exposure window. The scanner’s findings will include remediation guidance centered on enforcing TLS and avoiding the transmission of credentials without protection.

Remediation requires two coordinated changes: enforce TLS so that all communication is encrypted, and avoid sending credentials in the clear. Below are concrete, idiomatic Fiber examples that demonstrate a secure approach. These examples assume you have a valid TLS certificate and key available to the server.

1. Enforce HTTPS with a TLS-enabled Fiber server

Configure the Fiber instance to use TLS by providing certificate and key files. This ensures that all requests, including the Authorization header, are encrypted in transit.

const tls = require('tls');
const express = require('express'); // Fiber-compatible pattern
const app = express();

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

tls.createServer(tlsOptions, app).listen(8443, () => {
  console.log('HTTPS server running on port 8443');
});

2. Use middleware to require TLS and reject HTTP

Add a middleware that redirects HTTP traffic to HTTPS or closes the connection, ensuring no cleartext requests are processed.

app.all('*', (req, res, next) => {
  if (req.secure) {
    return next();
  }
  // Respond with a clear instruction to use HTTPS; in production you may redirect or reject
  res.status(400).send('HTTPS required');
});

3. Implement Basic Auth over HTTPS with constant-time comparison

When Basic Auth is necessary, validate credentials over the encrypted channel and avoid logging or echoing the header. Use a constant-time comparison to reduce timing side channels.

const auth = require('basic-auth');

app.get('/api/secure', (req, res) => {
  const user = auth(req);
  if (!user || !constantTimeCompare(user.name, 'admin') || !constantTimeCompare(user.pass, 'S3cur3P@ss!')) {
    res.set('WWW-Authenticate', 'Basic realm="example"');
    return res.status(401).send('Authentication required');
  }
  res.json({ ok: true });
});

function constantTimeCompare(a, b) {
  if (a.length !== b.length) return false;
  let result = 0;
  for (let i = 0; i < a.length; i++) {
    result |= a.charCodeAt(i) ^ b.charCodeAt(i);
  }
  return result === 0;
}

4. Avoid embedding credentials in source; prefer environment variables

Store usernames and passwords in environment variables or secure vaults and reference them at runtime. This reduces the risk of accidental exposure in version control.

const username = process.env.BASIC_AUTH_USER;
const password = process.env.BASIC_AUTH_PASS;
// Use username and password in the constantTimeCompare checks above

5. Complementary protections

While TLS and proper credential handling are essential, consider additional measures such as rate limiting and monitoring. middleBrick’s checks for Rate Limiting and Data Exposure can help you understand whether your current configuration reduces the attack surface. The CLI (middlebrick scan <url>) and the Web Dashboard make it easy to track changes over time, and the GitHub Action can enforce a minimum security score before merging code.