HIGH token leakagefiberbasic auth

Token Leakage in Fiber with Basic Auth

Token Leakage in Fiber with Basic Auth — how this specific combination creates or exposes the vulnerability

Token leakage in APIs using Fiber with HTTP Basic Authentication occurs when authentication credentials or session tokens are inadvertently exposed in logs, error messages, URLs, or headers. Because Basic Auth transmits credentials on every request (base64-encoded, not encrypted), any weak logging or misconfigured middleware can expose these tokens. In a black-box scan, middleBrick tests unauthenticated endpoints and checks whether authentication headers, cookies, or tokens are reflected in responses or leaked through verbose error handling.

When an API endpoint in Fiber is configured with Basic Auth but also exposes stack traces or debug information, an attacker can harvest credentials or session tokens from error responses. Additionally, if tokens are passed in query parameters or non-HTTPS endpoints are used, middleBrick flags these as data exposure risks. The scanner’s Authentication and Data Exposure checks specifically validate whether credentials or tokens appear in responses, and whether the transport layer lacks encryption, which is critical when Basic Auth is in use.

SSRF and unsafe consumption findings can also intersect with token leakage: if an endpoint accepts user-supplied URLs and forwards requests with inherited authentication headers, tokens may be exfiltrated to attacker-controlled endpoints. middleBrick’s SSRF and Unsafe Consumption checks look for patterns where outbound requests are made with sensitive headers or credentials. Because Basic Auth sends credentials in every request, any server-side request forgery dramatically increases the blast radius of token leakage.

In summary, the combination of Fiber routes using Basic Auth without HTTPS, improper error handling, and unsafe request forwarding can expose tokens and credentials. middleBrick detects these patterns by correlating authentication mechanisms with data exposure and SSRF checks, providing prioritized findings with severity and remediation guidance.

Basic Auth-Specific Remediation in Fiber — concrete code fixes

To remediate token leakage when using Basic Auth in Fiber, enforce HTTPS, avoid logging credentials, and use middleware that safely handles authorization without exposing tokens. Below are concrete Fiber code examples that align with secure practices and are validated by middleBrick’s checks.

1. Enforce HTTPS and use secure Basic Auth headers

Always serve your Fiber app over TLS and ensure the Authorization header is never logged or echoed back in responses.

const fiber = require('fiber');
const https = require('https');
const fs = require('fs');

const app = fiber();

// Basic Auth middleware that does not leak credentials
app.all('*', (req, res, next) => {
  const auth = req.headers['authorization'];
  if (!auth || !auth.startsWith('Basic ')) {
    res.status(401).send('Unauthorized');
    return;
  }
  const decoded = Buffer.from(auth.slice(6), 'base64').toString('utf-8');
  const [user, pass] = decoded.split(':');
  // validate user/pass securely (e.g., constant-time compare)
  if (user !== 'admin' || pass !== 's3cur3P@ss') {
    res.status(403).send('Forbidden');
    return;
  }
  // Do not store or echo the decoded token in logs or responses
  next();
});

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

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

2. Avoid query parameters and use secure cookie attributes if persisting sessions

Never pass tokens in URLs. If you must persist sessions, use HttpOnly, Secure cookies and short lifetimes.

const session = require('cookie-session');

app.use(session({
  name: 'session',
  keys: ['strong-session-secret'],
  secure: true,      // only sent over HTTPS
  httpOnly: true,    // not accessible via JavaScript
  sameSite: 'strict',
  maxAge: 24 * 60 * 60 * 1000
}));

app.get('/login', (req, res) => {
  // Perform Basic Auth validation as shown above
  req.session.user = 'admin'; // store minimal user info, never tokens or passwords
  res.send('Logged in');
});

3. Configure safe error handling and disable verbose stack traces

Ensure errors do not leak authentication details or stack traces that could aid token extraction.

app.set('trust proxy', 1);
app.use((err, req, res, next) => {
  // Log errors securely without exposing credentials or tokens
  console.error('Request failed:', err && err.message ? err.message : err);
  res.status(500).send('Internal Server Error');
});

4. Use middleware to validate and restrict headers

Remove or restrict headers that might echo tokens and enforce strict Content-Security-Policy and Referrer-Policy headers.

app.use((req, res, next) => {
  res.setHeader('Referrer-Policy', 'no-referrer');
  res.setHeader('Permissions-Policy', 'geolocation=()');
  next();
});

These patterns help ensure that token leakage is minimized when using Basic Auth in Fiber. middleBrick will verify the presence of HTTPS, safe error handling, and absence of credential reflection when scanning your endpoints.

Frequently Asked Questions

Does Basic Auth send credentials in every request?
Yes. With HTTP Basic Auth, the base64-encoded username:password pair is included in the Authorization header for every request. Without HTTPS, these credentials can be intercepted; even with HTTPS, any logging or mishandling of headers can lead to token leakage.
Can middleBrick detect token leakage when Basic Auth is used in Fiber?
Yes. middleBrick runs Authentication, Data Exposure, SSRF, and Unsafe Consumption checks to identify whether credentials or tokens are reflected in responses, transmitted over non-HTTPS endpoints, or exposed through unsafe request forwarding.