Pii Leakage in Fiber with Basic Auth

Basic Authentication over unencrypted channels is a common cause of PII leakage in Fiber applications. Because credentials are transmitted with every request as a base64-encoded string rather than a secure token, an attacker who intercepts traffic can recover usernames and passwords easily. In a black-box scan, middleBrick tests unauthenticated endpoints and checks whether sensitive data such as emails, names, or other PII is returned while Basic Auth is in use. When endpoints accept Basic Auth but do not enforce HTTPS, the credentials and any user-specific data can be exposed in transit.

For example, an endpoint that returns a user profile may include fields like email, full name, and phone number. If this endpoint also accepts Authorization: Basic base64(username:password), a passive network observer or a compromised proxy can observe both the credentials and the PII. middleBrick’s checks include verifying whether responses containing PII are served over unencrypted HTTP when Basic Auth credentials are present. Even if TLS is used, misconfigured servers that accept cleartext HTTP on alternate ports or redirect improperly can still expose PII when Basic Auth is relied upon without strict transport enforcement.

Another angle stems from server or application logs that inadvertently record Authorization headers. If Fiber routes or middleware log full request headers, Basic Auth credentials and PII present in query parameters or request bodies may be stored in plaintext log files. middleBrick’s endpoint checks include inspecting whether responses expose credentials via error messages or verbose output, and whether headers like Authorization appear in observable logs. Combined with insufficient rate limiting or weak access controls, this can amplify the impact of PII leakage by enabling enumeration or credential reuse across services.

middleBrick also evaluates whether endpoints using Basic Auth are covered by proper input validation and property authorization checks. Without explicit authorization checks per resource identifier, attackers may leverage BOLA or IDOR patterns to access other users’ PII by swapping identifiers in requests that still present valid Basic Auth credentials. Because the authentication and authorization boundaries are not clearly separated, an authenticated user can sometimes read or modify data belonging to others. The scanner tests whether PII is returned when different identity indicators are manipulated while a valid Basic Auth header is supplied, highlighting gaps where authentication does not equate to proper authorization.

Finally, the presence of Basic Auth can interact poorly with caching layers or reverse proxies that inadvertently cache responses containing PII. If responses include sensitive data and are cached without appropriate cache-control headers, subsequent requests—especially those made by an attacker who gains access to the cache—can disclose PII. middleBrick examines whether endpoints that accept Basic Auth set appropriate no-store directives and whether TLS configurations are robust. This helps ensure that PII is not persistently exposed through cached responses or weak cipher suites negotiated under the assumption that Basic Auth alone is sufficient protection.

To mitigate PII leakage in Fiber when using Basic Auth, enforce HTTPS for all routes, avoid logging Authorization headers, and combine Basic Auth with explicit authorization checks. Below are concrete, working examples that demonstrate secure configurations and request handling.

// secure-server.ts
import { app } from '@gorilla/middleware';
import { readFileSync } from 'fs';
import { basicAuth } from '@gorilla/basic-auth';

const httpsOptions = {
  key: readFileSync('/etc/ssl/private/server.key'),
  cert: readFileSync('/etc/ssl/certs/server.crt'),
};

const appInstance = app();

// Enforce HTTPS redirects on HTTP
appInstance.use((req, res, next) => {
  if (req.protocol !== 'https') {
    res.redirect(301, `https://${req.headers.host}${req.url}`);
    return;
  }
  next();
});

// Strip Authorization headers from logs
appInstance.use((req, res, next) => {
  const filteredHeaders = { ...req.headers };
  delete filteredHeaders['authorization'];
  // Use a safe logger that excludes sensitive headers
  console.info({ method: req.method, url: req.url, headers: filteredHeaders });
  next();
});

// Apply Basic Auth and explicit per-resource authorization
appInstance.get('/users/:id/profile', basicAuth({ realm: 'api' }), (req, res) => {
  const user = req.user; // from basic-auth middleware
  const requestedId = req.params.id;

  // Ensure the authenticated user can only access their own PII
  if (user.id !== requestedId) {
    res.status(403).json({ error: 'forbidden' });
    return;
  }

  // Return only necessary fields; avoid echoing credentials
  res.json({
    id: user.id,
    email: user.email,
    name: user.name,
  });
});

appInstance.listen(443, () => {
  console.log('HTTPS server running on port 443');
});

In this example, the server enforces HTTPS before any business logic, preventing credentials and PII from traversing in cleartext. The Authorization header is removed from logs to prevent persistence of PII in log stores. Authorization is checked explicitly by comparing the authenticated user identifier with the requested resource identifier, ensuring that Basic Auth provides authentication but not implicit access to others’ data. This pattern reduces the risk of PII leakage via IDOR when Basic Auth credentials are present.

For API consumers, document that Basic Auth must only be used over TLS and that clients should avoid sending credentials in URLs or query parameters. Configure TLS with strong ciphers and prefer token-based alternatives where feasible. Combine middleBrick scans—run via the CLI with middlebrick scan <url> or in CI/CD with the GitHub Action—to continuously verify that PII is not exposed on endpoints using Basic Auth and that HTTPS is enforced. These practices align with findings mapped to frameworks such as OWASP API Top 10 and relevant compliance controls.